Amir Rohan wrote:
> But implementing a mechanism that can be used by other features in
> the future seems the deciding factor here, rather then the brevity of a
> bespoke mini-language.
One decision to be taken is which among JSON or mini-language is better for
the SR setting.
Mini language can fit into the postgresql.conf single line.
For JSON currently a different file is used. But as said earlier, in case
composite types are required in future for other parameters then having
multiple .conf files does not make sense. To avoid this we can:
- support multi-line GUC which would be helpful for other comma-separated
conf values along with s_s_names. (This can make mini-language more
readable as well)
- Allow JSON support in postgresql.conf. So that other parameters in future
can use JSON as well within postgresql.conf.
What are the chances of future data requiring JSON? I think rare.
> > And I'm really not much in favor of a separate file; if we go that way
> > then we're going to have to reinvent a huge amount of infrastructure
> > that already exists for GUCs.
>
> Adding support for JSON objects (or some other kind of composite data
> type)
> to the .conf parser would negate the need for one, and would also solve
> the
> problem being discussed for future cases.
With the current pg_syncinfo file, the only code added was to check the
pg_syncinfo file in the specified path and read the entire content of the
file into a variable which was used for further parsing which could have
been avoided with multi-line GUC.
-----
Beena Emerson
--
View this message in context:
http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5869285.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
