Re: [PATCH] Introduce unified support for composite GUC options

út 23. 9. 2025 v 5:38 odesílatel Чумак Антон <a(dot)chumak(at)postgrespro(dot)ru>
napsal:

> Sorry, I replied to the email without the hackers tag, so some of our
> correspondence was not saved on hackers. Therefore, I will quote my answer
> and Pavel's questions and remarks below.
>
>
> >>Thank you for your question!
> >>Composite parameters in a configuration system are needed to describe
> complex objects that have many interrelated parameters. Such examples
> already exist in PostgreSQL: synchronous_standby_names or primary_conninfo.
> And with these parameters, there are some difficulties for both developers
> and DBMS administrators.
> >Do we really need this?
> >synchronous_standby_names is a simple list and primary_conninfo is just a
> string - consistent with any other postgresql connection string.
>
>
> synchronous_standby_names is somewhat more complicated than a regular list
> . Its first field is the mode, the second is the number of required
> replicas, and only then is the list. Note its check hook. A parser is
> called there, whose code length exceeds the rest of the logic associated
> with this parameter. This is exactly the kind of problem the patch solves.
>
>
> >If you need to store more complex values, why you don't use integrated
> json parser?
> >
> >I don't like you introduce new independent language just for GUC and this
> is not really short (and it is partially redundant to json). Currently
> working with GUC is simple, because supported operations and formats are
> simple.
>
>
> I looked at the json value parsing function with the ability to use custom
> semantic actions, and it might be a really great idea to use it instead
> of a self-written parser. Then the composite values will have the standard
> json syntax, and the patch will probably decrease in size.
>

when you use json, then what is the benefit from your patch?

It is not too big difference if I set value by SET command or by SELECT
set_config()

for some complex configuration I don't think so the best way is a direct
modification of some complex value. You still need some helper functions,
and these functions can hide all complexity. More - the performance there
is not important, so plpgsql can be used well - and working with json in
plpgsql is almost comfortable.

> >>For administrators:
> >> 1. The value of such parameters can only be written in full as a string
> and there is no way to access individual fields or substructure.
> >> 2. Each such parameter has its own syntax (compare the syntax
> description of synchronous_standby_names and primary_conninfo)
> >>For developers:
> >>1. For each composite parameter, you need to write your own parser that
> will parse the string value, instead of just describing the logic.
> >>Personally, I needed to describe the cluster configuration. A cluster
> consists of nodes interconnected by some logic. And it turns out that in
> the current system, I need to write 1 more parser for this parameter, and
> the user will have to learn 1 more syntax.
> >>This patch creates a unified approach to creating composite options,
> provides a unified syntax for values of composite types, adds the ability
> to work with fields and substructures, and eliminates the need for
> developers to write their own parsers for each composite parameter
> >looks like overengineering for me - when you have complex configuration -
> isn't better to use table? Or json value - if you need to store all to one
> GUC.
>
>
> Tables are not suitable for storing configuration, because we need GUC
> capabilities such as analyzing the source of a new value, working at the
> time of postmaster startup, SET LOCAL support, etc.
>
>
> >Another issue is using symbols -> for dereferencing directly from the
> scanner. It can break applications that use the same symbols as a custom
> operator.
>
>
> I made the dereference operator look like -> because the dot is already
> used to separate the class of names from options. It is possible to use a
> dot, but then we need to agree that composite parameters and extensions
> must not have the same names in order to avoid collisions.
>
> Best regards
>
> Anton Chumak
>
>
>
>