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
