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 <[email protected]> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
