Josh Berkus <josh@agliodbs.com> writes: > On 07/17/2015 04:36 PM, Jim Nasby wrote: >> I'm guessing it'd be really ugly/hard to support at least this GUC being >> multi-line?
> Mind you, multi-line GUCs would be useful otherwise, but we don't want > to hinge this feature on making that work.
I'm pretty sure that changing the GUC parser to allow quoted strings to continue across lines would be trivial.
Agreed
The problem with it is not that it's hard, it's that omitting a closing quote mark would then result in the entire file being syntactically broken, with the error message(s) almost certainly pointing somewhere else than where the actual mistake is.
That depends upon how we specify line-continuation. If we do it with starting and ending quotes, then we would have the problem you suggest. If we required each new continuation line to start with a \ then it wouldn't (or similar). Or perhaps it gets its own file even, an idea raised before.
Do we really want such a global reduction in friendliness to make this feature easier?
Clearly not, but we must first decide whether that is how we characterise the decision.
synchronous_standby_name= is already 25 characters, so that leaves 115 characters - are they always single byte chars?
It's not black and white for me that JSON necessarily requires >115 chars whereas other ways never will do.
What we are discussing is expanding an existing parameter to include more information. If Josh gets some of the things he's been asking for, then the format will bloat further. It doesn't take much for me to believe it might expand further still, so my view from the discussion is that we'll likely need to expand beyond 115 chars one day whatever format we choose.
I'm personally ambivalent what the exact format is that we choose; I care much more about the feature than the syntax, always. My contribution so far was to summarise what I thought was the majority opinion, and to challenge the thought that JSON had no discernible benefit. If the majority view is different, I have no problem there.
Clusters of 20 or more standby nodes are reasonably common, so those limits do seem a little small. Synchronous commit behavior is far from being the only cluster metadata we need to record. I'm thinking now that this illustrates that this is the wrong way altogether and we should just be storing cluster metadata in database tables, which is what was discussed and agreed at the BDR meeting at PGCon.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services