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
