út 23. 9. 2025 v 5:38 odesílatel Чумак Антон <[email protected]> napsal:
> 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. > when you use json, then what is the benefit from your patch? It is not too big difference if I set value by SET command or by SELECT set_config() for some complex configuration I don't think so the best way is a direct modification of some complex value. You still need some helper functions, and these functions can hide all complexity. More - the performance there is not important, so plpgsql can be used well - and working with json in plpgsql is almost comfortable. > >>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 > > > >
