Re: BUG #17045: 14 Beta Tighten up allowed names for custom GUC parameters breaks PostgREST

Hi Tom,

Thanks for the quick and thoughtful reply. Really appreciate your support!

I would revise my statement to say this change to PostgreSQL 14 would
significantly break existing PostgREST applications, to the point that they
would be unable to upgrade to 14. The way PostgREST works, these GUC
parameters are used extensively in user defined functions and SQL queries,
with the "." used as the standard way to namespace parameter elements.
Syntax-wise, it would be similar as if PostgreSQL 14 changed the
schema/table qualifier from `.` to `_`. Developers could migrate all their
functions and queries before upgrading to 14, but that would be a
significant and required change for applications to continue working.

Regarding the error detail, here are some ideas for adding multiple "."
characters. Happy for any feedback:

1. Custom parameter names must include at least one namespace, such
as "namespace.custom".
2. Custom parameter names must include at least one namespace character
".", such as "namespace.parameter" or " namespace.parameter.one".
3. Custom parameter names must include at least one ".", such
as "custom.parameter".
4. Custom parameter names must include at least one ".", such
as "custom.one" or "custom.one.two".
5. Custom parameter names must include at least one ".", such
as "one.two" or "one.two.three".
6. Custom parameter names must include two or more components, such as
"one.two" or "one.two.three".

With these examples, I'm hoping to show that custom parameters must have at
least one "namespace" or "." character. Some give an extra example with two
dots to show that you can have multiple "namespaces". Again, happy to hear
your thoughts!

Also, thanks for all your work on PostgreSQL! This database is Amazing
(been using it for 20 years now) and excited to get production workloads on
14!

-Robert

On Wed, Jun 2, 2021 at 3:19 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> PG Bug reporting form <noreply(at)postgresql(dot)org> 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
>