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

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.

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