Thread

Re: [PATCH] Allow complex data for GUC extra.

Andrew Dunstan <andrew@dunslane.net> — 2025-11-21T22:26:52Z

On 2025-11-18 Tu 2:56 PM, Robert Haas wrote:
>
> 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.


+1


> 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?
>

If GUC A depends for sanity on the value of GUC B, it seems rather odd 
to force them to be independent at the grammar level. A structured GUC 
would make more sense in such a case.

One of the things that bothers me a bit here is that we seem to be 
inventing a bunch of micro-languages to deal with structured GUC data. 
<asbestos-mode> Maybe they could all be JSON?</>


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com