>On 07/16/15, Robert Haas wrote:
>    
>>> * 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 think it will be rare to need to parse the postgresql.conf string,
>> manipulate it programatically, and then put it back.
>
>On Sun, Jul 19, 2015 at 4:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>>> On 07/17/2015 04:36 PM, Jim Nasby wrote:
>>>> I'm guessing it'd be really ugly/hard to support at least this GUC being
>>>> multi-line?
>>
>>> Mind you, multi-line GUCs would be useful otherwise, but we don't want
>>> to hinge this feature on making that work.
>>
>> Do we really want such a global reduction in friendliness to make this
>> feature easier?
>
>Maybe shoehorning this into the GUC mechanism is the wrong thing, and
>what we really need is a new config file for this.  The information
>we're proposing to store seems complex enough to justify that.

 

It seems like:

1) There's a need to support structured data in configuration for future

needs as well, it isn't specific to this feature.
2) There should/must be a better way to validate configuration then
to restarting the server in search of syntax errors.

 

Creating a whole new configuration file for just one feature *and* in a different

Now, about JSON.... (Earlier Upthread):

 
On 07/01/15, Peter Eisentraut wrote:

> On 6/26/15 2:53 PM, Josh Berkus wrote:
> > I would also suggest that if I lose this battle and
> > we decide to go with a single stringy GUC, that we at least use JSON
> > instead of defining our out, proprietary, syntax?
>  
> Does JSON have a natural syntax for a set without order?

 

No. Nor Timestamps. It doesn't even distingush integer from float

(Though parsers do it for you in dynamic languages). It's all because

of its unsightly javascript roots.
 

Other have found JSON unsatisfactory before. For example, the clojure community

has made (at least) two attempts at alternatives, complete with the meh adoption

rates you'd expect despite being more capable formats:

 

http://blog.cognitect.com/blog/2014/7/22/transit
https://github.com/edn-format/edn

 

There's also YAML, TOML, etc', none as universal as JSON. But to reiterate, JSON itself

has Lackluster type support (no sets, no timestamps), is verbose, iseasy to malform when editing

(missed a curly brace, shouldn't use a single quote), isn't extensible, and my personal pet peeve

is that it doesn't allow non-string or bare-string keys in maps (a.k.a "death by double-quotes").

Python has the very natural {1,2,3} syntax for sets, but of course that's not part of JSON.

 

If  JSON wins out despite all this, one alternative not discussed is to extend

the .conf parser to accept json dicts as a fundamental type. e.g.:

 

###

data_directory = 'ConfigDir'   
port = 5432
work_mem = 4MB
hot_standby = off
client_min_messages = notice
log_error_verbosity = default
autovacuum_analyze_scale_factor = 0.1
synch_standby_config = {
  "sync_info": {
    "nodes": [
      {
        "priority": 1,
        "group": "cluster1"
      },
      "A"
    ],
    "quorum": 3
  },
  "groups": {
    "cluster1": [
      "B",
      "C"
    ]
  }
}

 

This *will* break someone's perl I would guess. Ironically, those scripts wouldn't have broken if

some structured format were in use for the configuration data when they were written...

`postgres --describe-config` is also pretty much tied to a line-oriented configuration.

 

Amir

 

p.s.

 

MIA configuration validation tool/switch should probably get a thread too.