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

<div style="font-family: Verdana;font-size: 12.0px;"><div><div>>On 07/16/15, Robert Haas wrote:<br /> >    <br />
>>>* Developers will immediately understand the format<br /> >><br /> >>I doubt it.  I think any
formatthat we pick will have to be carefully<br /> >>documented.  People may know what JSON looks like in
general,but they<br /> >>will not immediately know what bells and whistles are available in<br /> >>this
context.<br/> >><br /> >>> * Easy to programmatically manipulate in a range of languages<br />
>><br/> >> <...> I think it will be rare to need to parse the postgresql.conf string,<br /> >>
manipulateit programatically, and then put it back.<br /> ><br /> >On Sun, Jul 19, 2015 at 4:16 PM, Tom Lane
<tgl(at)sss(dot)pgh(dot)pa(dot)us>wrote:<br /> >> Josh Berkus <josh(at)agliodbs(dot)com> writes:<br
/>>>> On 07/17/2015 04:36 PM, Jim Nasby wrote:<br /> >>>> I'm guessing it'd be really ugly/hard to
supportat least this GUC being<br /> >>>> multi-line?<br /> >><br /> >>> Mind you,
multi-lineGUCs would be useful otherwise, but we don't want<br /> >>> to hinge this feature on making that
work.<br/> >><br /> >> Do we really want such a global reduction in friendliness to make this<br />
>>feature easier?<br /> ><br /> >Maybe shoehorning this into the GUC mechanism is the wrong thing, and<br
/>>what we really need is a new config file for this.  The information<br /> >we're proposing to store seems
complexenough to justify that.</div><div> </div><div>It seems like:</div><div>1) There's a need to support structured
datain configuration for future</div><div>needs as well, it isn't specific to this feature.<br /> 2) There should/must
bea better way to validate configuration then<br /> to restarting the server in search of syntax
errors.</div><div> </div><div>Creatinga whole new configuration file for just one feature *and* in a different
<div>formatseems suboptimal.  What happens when the next 20 features need structured</div><div>config data, where does
thatgo? will there be additional JSON config files *and* perhaps</div><div>new mini-language values in .conf as
developmentcontinues?  How many dedicated</div><div>configuration files is too many?</div></div><div>Now, about
JSON....(Earlier Upthread):</div><div> <br /> On 07/01/15, Peter Eisentraut wrote:</div><div>> On 6/26/15 2:53 PM,
JoshBerkus wrote:<br /> > > I would also suggest that if I lose this battle and<br /> > > we decide to go
witha single stringy GUC, that we at least use JSON<br /> > > instead of defining our out, proprietary,
syntax?<br/> >  <br /> > Does JSON have a natural syntax for a set without order?</div><div> </div><div>No. Nor
Timestamps.It doesn't even distingush integer from float</div><div>(Though parsers do it for you in dynamic languages).
It'sall because</div><div>of its unsightly javascript roots.<br />  </div><div><div>The current patch is now forced by
JSONto conflate sets and lists, so</div><div>un/ordered semantics are no longer tied to type but to the specific
configurationkeys.</div><div>So, If a feature ever needs a key where the difference between set and list
matters</div><div>andneeds to support both, you'll need seperate keys (both with lists, but meaning different
things)</div><div>ora separate "mode" key or something. Not terrible, just iffy.</div><div> </div></div><div>Other have
foundJSON unsatisfactory before. For example, the clojure community</div><div>has made (at least) two attempts at
alternatives,complete with the meh adoption</div><div>rates you'd expect despite being more capable
formats:</div><div> </div><div>http://blog.cognitect.com/blog/2014/7/22/transit<br/>
https://github.com/edn-format/edn</div><div> </div><div>There'salso YAML, TOML, etc', none as universal as JSON. But to
reiterate,JSON itself</div><div>has Lackluster type support (no sets, no timestamps), is verbose, iseasy to malform
whenediting</div><div>(missed a curly brace, shouldn't use a single quote), isn't extensible, and my personal pet
peeve</div><div>isthat it doesn't allow non-string or bare-string keys in maps (a.k.a "death by double-quotes").</div>
 <div>Python has the very natural {1,2,3} syntax for sets, but of course that's not part of
JSON.</div><div> </div><div>If JSON wins out despite all this, one alternative not discussed is to extend</div><div>the
.confparser to accept json dicts as a fundamental type. e.g.:</div><div> </div><div>###</div><div>data_directory =
'ConfigDir'  <br /> port = 5432<br /> work_mem = 4MB<br /> hot_standby = off<br /> client_min_messages = notice<br />
log_error_verbosity= default<br /> autovacuum_analyze_scale_factor = 0.1<br /> synch_standby_config = {<br />  
"sync_info":{<br />     "nodes": [<br />       {<br />         "priority": 1,<br />         "group": "cluster1"<br />
     },<br />       "A"<br />     ],<br />     "quorum": 3<br />   },<br />   "groups": {<br />     "cluster1": [<br />
     "B",<br />       "C"<br />     ]<br />   }<br /> }</div><div> </div><div>This *will* break someone's perl I would
guess.Ironically, those scripts wouldn't have broken if</div><div>some structured format were in use for the
configurationdata when they were written...</div><div>`postgres --describe-config` is also pretty much tied to a
line-orientedconfiguration.</div><div> </div><div>Amir</div><div> </div><div>p.s.</div><div> </div><div>MIA
configurationvalidation tool/switch should probably get a thread too.</div><div> </div></div></div>