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

On Fri, Nov 21, 2025 at 05:26:52PM -0500, Andrew Dunstan wrote:
> > 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?</>

As long as you didn't say XML, we are good. ;-)

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.