po 22. 9. 2025 v 12:03 odesílatel Pavel Stehule <[email protected]> napsal:
> Hi > > po 22. 9. 2025 v 11:13 odesílatel Чумак Антон <[email protected]> > 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 >> >> >> >
