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

Hi

po 22. 9. 2025 v 11:13 odesílatel Чумак Антон <a(dot)chumak(at)postgrespro(dot)ru>
napsal:

> 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.

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.

Regards

Pavel

> 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.

Regards

Pavel

> Best regards
>
> Anton Chumak
>
>
>