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
