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

On Fri, Nov 21, 2025 at 5:26 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> 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?</>

I can understand why you (or anyone) would suggest this, but I don't
think it would actually be better, for three reasons. First, changing
the format for something like synchronous_standby_names would be a
backward compatibility break. Second, I suspect the resulting format
would be more long-winded. Instead of ANY 2 (foo, bar, baz) you'd have
to write something like { 'op' => 'ANY', 'num' => 2, 'servers' => [
'foo', 'bar', 'baz' ]}. Third, if my experience with using JSON for
backup manifests is any indication, it would actually add
significantly more code. The JSON parser doesn't do all the work for
you, because you have to do semantic validation of the JSON
afterwards. See parse_manifest.c for an example of what I mean.

I think the real strength of JSON is not that it's any easier to use
or objectively better than a mini-language, but that it's a standard.
If we threw out the entire postgresql.conf format and replaced it with
a big JSON document whose keys were GUC names and whose values were
all JSON values, then somebody could manipulate that whole document
using any JSON tool that they like, and that would probably be handy
for some people. Same if we made the whole thing XML or whatever. We
would probably make life harder for ourselves, but if it had enough
benefit for users, it might worth it. I don't think users would
actually be happy about such a change and I'm not proposing it, but
it's the kind of thing I can imagine making sense hypothetically. If
we were starting from scratch rather than trying to maintain
compatibility with our previous releases, it would be worth thinking
about.

Absent that, I think ad-hoc mini-languages are a pretty good idea. By
designing something that does exactly what you need and nothing else,
you can often create something that is clear, succinct, and easy for
users to learn. synchronous_standby_names is a good example: it's not
that hard to understand how it works, it does what we need, and it
doesn't become any easier to use if you make it JSON or XML or
whatever. The plan advice mini-language is a more arguable case, but I
based that on existing mini-languages that do similar things and then
adapted it for what I was trying to do, which means that people
familiar with those other things might have an easier learning curve.
I am of course open to alternate ideas of how that language should
work, and there are definitely things about it that I don't like. But
as far as I can see, none of the things I'm unhappy about would be
fixed by using JSON.

In response to your asbestos-mode tag, let me say that none of this is
intended to flame you, or to express outrage. I know a lot of people
would say that my appreciation for a well-chosen mini-language is
wrong-headed, and you may be one of them, and that's fair enough. But
I see it differently, so this is just to explain my view of it.

--
Robert Haas
EDB: http://www.enterprisedb.com