| From: | "Amir Rohan" <amir(dot)rohan(at)mail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Support for N synchronous standby servers - take 2 |
| Date: | 2015-09-23 04:11:15 |
| Message-ID: | trinity-4258acb0-b75a-4bf1-9657-f8237883cd0d-1442981475318@3capp-mailcom-lxa02 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
<html><head></head><body><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 format that 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/>
>> manipulate it 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 support at least this GUC being<br/>
>>>> multi-line?<br/>
>><br/>
>>> Mind you, multi-line GUCs 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 complex enough to justify that.</div>
<div> </div>
<div>It seems like:</div>
<div>1) There's a need to support structured data in configuration for future</div>
<div>needs as well, it isn't specific to this feature.<br/>
2) There should/must be a better way to validate configuration then<br/>
to restarting the server in search of syntax errors.</div>
<div> </div>
<div>Creating a whole new configuration file for just one feature *and* in a different
<div>format seems suboptimal. What happens when the next 20 features need structured</div>
<div>config data, where does that go? will there be additional JSON config files *and* perhaps</div>
<div>new mini-language values in .conf as development continues? 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, Josh Berkus wrote:<br/>
> > I would also suggest that if I lose this battle and<br/>
> > we decide to go with a 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's all because</div>
<div>of its unsightly javascript roots.<br/>
</div>
<div>
<div>The current patch is now forced by JSON to conflate sets and lists, so</div>
<div>un/ordered semantics are no longer tied to type but to the specific configuration keys.</div>
<div>So, If a feature ever needs a key where the difference between set and list matters</div>
<div>and needs to support both, you'll need seperate keys (both with lists, but meaning different things)</div>
<div>or a separate "mode" key or something. Not terrible, just iffy.</div>
<div> </div>
</div>
<div>Other have found JSON 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's also 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 when editing</div>
<div>(missed a curly brace, shouldn't use a single quote), isn't extensible, and my personal pet peeve</div>
<div>is that 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 .conf parser 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 configuration data when they were written...</div>
<div>`postgres --describe-config` is also pretty much tied to a line-oriented configuration.</div>
<div> </div>
<div>Amir</div>
<div> </div>
<div>p.s.</div>
<div> </div>
<div>MIA configuration validation tool/switch should probably get a thread too.</div>
<div> </div>
</div></div></body></html>
| Attachment | Content-Type | Size |
|---|---|---|
| unknown_filename | text/html | 6.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2015-09-23 05:11:35 | Re: PATCH: use foreign keys to improve join estimates v1 |
| Previous Message | Charles Clavadetscher | 2015-09-23 02:36:05 | Re: unclear about row-level security USING vs. CHECK |