Thread

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

Bruce Momjian <bruce@momjian.us> — 2025-11-22T19:00:05Z

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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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