Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Amir Rohan
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id trinity-2596e0cb-af50-45e6-adf4-8f8c0ff8b19a-1443061598299@3capp-mailcom-lxa12
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Support for N synchronous standby servers - take 2
List pgsql-hackers
> Sent: Thursday, September 24, 2015 at 3:11 AM
> 
> From: "Tom Lane" <tgl@sss.pgh.pa.us>
> Robert Haas <robertmhaas@gmail.com> writes:
> > Well, I think that if we create our own mini-language, it may well be
> > possible to make the configuration for this compact enough to fit on
> > one line. If we use JSON, I think there's zap chance of that. But...
> > that's just what *I* think.
>> 

I've implemented a parser that reads you mini-language and dumps a JSON
equivalent. Once you start naming groups the line fills up quite quickly,
and on the other hands the JSON is verbose and fiddely.
But implementing a mechanism that can be used by other features in
the future seems the deciding factor here, rather then the brevity of a 
bespoke mini-language.

> 
> <...> we're best off avoiding the challenges of dealing with multi-line 
> postgresql.conf entries.
> 
> And I'm really not much in favor of a separate file; if we go that way
> then we're going to have to reinvent a huge amount of infrastructure
> that already exists for GUCs.
> 
> regards, tom lane

Adding support for JSON objects (or some other kind of composite data type) 
to the .conf parser would negate the need for one, and would also solve the
problem being discussed for future cases.
I don't know whether that would break some tooling you care about, 
but if there's interest, I can probably do some of that work.



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!
Next
From: Robert Haas
Date:
Subject: Re: Parallel Seq Scan