>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
format seems suboptimal.  What happens when the next 20 features need structured
config data, where does that go? will there be additional JSON config files *and* perhaps
new mini-language values in .conf as development continues?  How many dedicated
configuration files is too many?
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.
The current patch is now forced by JSON to conflate sets and lists, so
un/ordered semantics are no longer tied to type but to the specific configuration keys.
So, If a feature ever needs a key where the difference between set and list matters
and needs to support both, you'll need seperate keys (both with lists, but meaning different things)
or a separate "mode" key or something. Not terrible, just iffy.
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:
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"
    "quorum": 3
  "groups": {
    "cluster1": [
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.
MIA configuration validation tool/switch should probably get a thread too.