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

po 22. 9. 2025 v 12:03 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

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

Another issue is using symbols -> for dereferencing directly from the
scanner. It can break applications that use the same symbols as a custom
operator.

Regards

Pavel

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