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
