| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Support for N synchronous standby servers - take 2 |
| Date: | 2015-07-17 23:36:55 |
| Message-ID: | 55A99197.30403@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 7/16/15 12:40 PM, Robert Haas wrote:
>> >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.)
Brevity goes both ways, but I don't think that's the real problem here;
it's the lack of multi-line support. The JSON that's been proposed makes
you work really hard to track what level of nesting you're at, while
every alternative format I've seen is terse enough to be very clear on a
single line.
I'm guessing it'd be really ugly/hard to support at least this GUC being
multi-line?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2015-07-18 00:03:48 | Re: Support retrieving value from any sequence |
| Previous Message | Alvaro Herrera | 2015-07-17 23:28:19 | Re: WAL test/verification tool |