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.
For administrators: * 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. *
Each such parameter has its own syntax (compare the syntax description of
synchronous_standby_names and primary_conninfo)
For developers: * 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.
Best regards
Anton Chumak
