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-uxmF3MKyDB9mu38cJ7Jg@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.