On Tue, Nov 18, 2025 at 1:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm really still dubious that this entire project is worthwhile.
> I think it is basically building support for GUCs whose values
> are unreasonably complicated, and would be better off if they
> got redesigned. Also, right now might be a bad time to be
> adding complexity to guc.c, in view of discussions such as [1].
What motivated me to care about this was pg_plan_advice.advice, which
is indeed arguably too complicated to be a GUC, but I don't have a
better idea right now. I thought about using a pg_upgrade-support
style thing, like SELECT pg_plan_advice.next_advice_is('text value')
-- but this seems really awkward to me in the context of code running
inside of a function, because we don't know whether the query we're
about to see is going to get planned or not. And while someone may
think "just pass it through via the SQL comments" is a solution to
this problem, I find I cannot agree for a whole long list of reasons.
It seems to most naturally fit as a GUC, even though that's not a
great fit.
Also, that's not the only case we have of something like this.
check_synchronous_standby_names and check_synchronized_standby_slots
are good, existing examples of where substantial parsing is required
and then effort must be expended to get it back into a single palloc'd
chunk. check_backtrace_functions is an interesting example too: would
we really pick this particular representation if the GUC
infrastructure didn't require it? I have my doubts.
In general, I don't think that whether or not a GUC's parsed value can
be serialized easily into a single palloc'd chunk is a good measure of
whether it's too complicated. I agree, of course, that we shouldn't
randomly sandwhich a bunch of disparate values into a single GUC --
several separate GUCs is better. However, what about a value that
intrinsically has some internal structure? We originally thought that
we wanted synchronous_standby_names to just be a list of standbys,
which barely qualifies as internal structure and so fits with the idea
of a single palloc'd chunk, but then we decided we wanted to allow
prefixing that list stuff like ANY 2 or FIRST 3. Does that make it no
longer suitable to be a GUC? What if we had instead decided to allow
nested structure, like synchronous_standby_names = a, (b, c), d? That
definitely isn't nice for a flat structure, but I doubt anyone would
like it if that adjustment suddenly meant it had to be some other kind
of thing rather than a GUC, and what would the other thing be, anyway?
--
Robert Haas
EDB: http://www.enterprisedb.com
