On Thu, Jul 16, 2015 at 1:32 PM, Simon Riggs <simon@2ndquadrant.com> 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.
However, I'm not trying to ram my idea through; I'm just telling you my opinion.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
