Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1loXKv-0006is-6K for pgsql-bugs@arkaria.postgresql.org; Wed, 02 Jun 2021 20:19:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1loXKt-0002bM-5p for pgsql-bugs@arkaria.postgresql.org; Wed, 02 Jun 2021 20:19:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1loXKs-0002bE-VU for pgsql-bugs@lists.postgresql.org; Wed, 02 Jun 2021 20:19:30 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1loXKq-000445-TJ for pgsql-bugs@lists.postgresql.org; Wed, 02 Jun 2021 20:19:30 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 152KJRT8165911; Wed, 2 Jun 2021 16:19:27 -0400 From: Tom Lane To: robert.sosinski@reactive.io cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17045: 14 Beta Tighten up allowed names for custom GUC parameters breaks PostgREST In-reply-to: <17045-6a4a9f0d1513f72b@postgresql.org> References: <17045-6a4a9f0d1513f72b@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Wed, 02 Jun 2021 19:34:59 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <165909.1622665167.1@sss.pgh.pa.us> Date: Wed, 02 Jun 2021 16:19:27 -0400 Message-ID: <165910.1622665167@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > This change allows there to only be one `.` in the GUC key. The problem is > that PostgreSQL uses multiple `.` in GUC keys to nest parameters, such as > `request.jwt.claim.role`. As such this would be a change that significantly > breaks PostgREST. Hmm. Reading the link you provide, it seems like PostgREST might be moving away from that anyway. So I think "significantly breaks" may be an overstatement. Still, we did expect that this wouldn't break any reasonable usage, and there's an argument that what PostgREST did is reasonable. (But ... do they have any cases where individual components of such a name aren't valid identifiers?) The larger question here is whether we (core PG) would ever want to introduce special interpretations of custom GUC names with more than two components. It doesn't sound out of the question, but on the other hand I don't know of any active work in such a direction. It might be better to let this usage alone until there's a more pressing reason to break it. Question for you: if we did modify this, how would you restate the hint: DETAIL: Custom parameter names must be of the form "identifier.identifier". I'm having a hard time coming up with a similarly succinct explanation of "two or more identifiers separated by dots". regards, tom lane