Re: Support for N synchronous standby servers - take 2
От
Amir Rohan
Тема
Re: Support for N synchronous standby servers - take 2
Дата
Msg-id
trinity-2596e0cb-af50-45e6-adf4-8f8c0ff8b19a-1443061598299@3capp-mailcom-lxa12
Ответ на
Список
Дерево обсуждения
Re: Support for N synchronous standby servers - take 2 "Amir Rohan" <amir.rohan@mail.com>
Re: Support for N synchronous standby servers - take 2 Robert Haas <robertmhaas@gmail.com>
Re: Support for N synchronous standby servers - take 2 Tom Lane <tgl@sss.pgh.pa.us>
Re: Support for N synchronous standby servers - take 2 "Amir Rohan" <amir.rohan@mail.com>
Re: Support for N synchronous standby servers - take 2 Beena Emerson <memissemerson@gmail.com>
Re: Support for N synchronous standby servers - take 2 Beena Emerson <memissemerson@gmail.com>
Re: Support for N synchronous standby servers - take 2 Amit Kapila <amit.kapila16@gmail.com>
Re: Support for N synchronous standby servers - take 2 Robert Haas <robertmhaas@gmail.com>
Re: Support for N synchronous standby servers - take 2 Masahiko Sawada <sawada.mshk@gmail.com>
Re: Support for N synchronous standby servers - take 2 Michael Paquier <michael.paquier@gmail.com>
Re: Support for N synchronous standby servers - take 2 Beena Emerson <memissemerson@gmail.com>
Re: Support for N synchronous standby servers - take 2 Michael Paquier <michael.paquier@gmail.com>
Re: Support for N synchronous standby servers - take 2 Masahiko Sawada <sawada.mshk@gmail.com>
> Sent: Thursday, September 24, 2015 at 3:11 AM > > From: "Tom Lane" > Robert Haas 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 по дате отправления