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:
- Custom parameter names must include at least one namespace, such as "namespace.custom".
- Custom parameter names must include at least one namespace character ".", such as "namespace.parameter" or " namespace.parameter.one".
- Custom parameter names must include at least one ".", such as "custom.parameter".
- Custom parameter names must include at least one ".", such as "custom.one" or "custom.one.two".
- Custom parameter names must include at least one ".", such as "one.two" or "one.two.three".
- 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
PG Bug reporting form <noreply@postgresql.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