Robert Haas wrote: > > On Thu, Jul 16, 2015 at 1:32 PM, Simon Riggs <simon@> wrote: > >> Personally, I think we're going to find that using JSON for this > >> rather than a custom syntax makes the configuration strings two or > >> three times as long for > > > > They may well be 2-3 times as long. Why is that a negative? > > In my opinion, brevity makes things easier to read and understand. We > also don't support multi-line GUCs, so if your configuration takes 140 > characters, you're going to have a very long line in your > postgresql.conf (and in your pg_settings output, etc.) > > > * No additional code required in the server to support this syntax (so > no > > bugs) > > I think you'll find that this is far from true. Presumably not any > arbitrary JSON object will be acceptable. You'll have to parse it as > JSON, and then validate that it is of the expected form. It may not > be MORE code than implementing a mini-language from scratch, but I > wouldn't expect to save much. > > > * Developers will immediately understand the format > > I doubt it. I think any format that we pick will have to be carefully > documented. People may know what JSON looks like in general, but they > will not immediately know what bells and whistles are available in > this context. > > * Easy to programmatically manipulate in a range of languages > > I agree that JSON has that advantage, but I doubt that it is important > here. I would expect that people might need to generate a new config > string and dump it into postgresql.conf, but that should be easy with > any reasonable format. I think it will be rare to need to parse the > postgresql.conf string, manipulate it programatically, and then put it > back. As we've already said, most configurations are simple and > shouldn't change frequently. If they're not or they do, that's a > problem of itself. >
All points here are valid and I would prefer a new language over JSON. I agree, the new validation code would have to be properly tested to avoid bugs but it wont be too difficult. Also I think methods that generate WAL record is avoided because any attempt to change the syncrep settings will go in indefinite wait when a mandatory sync candidate (as per current settings) goes down (Explained in earlier post id: cahgqgwe_-hczw687b4sdmwqakkpcu-uxmf3mkydb9mu38cj...@mail.gmail.com) ----- Beena Emerson -- View this message in context: http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5858255.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
