On 9/26/14, 3:22 PM, Tom Lane wrote:
We could alternatively try to split up these cases into multiple GUCs, which I guess is what you're imagining as a "multi-year battle".
No, I was just pointing out that even the cleanest major refactoring possible here is going to result in broken config files complaints for years. And no matter how well that goes, a second rewrite in the next major version, addressing whatever things nobody saw coming in the first redesign, is a very real possibility. The minute the GUC box is opened that far, it will not close up again in a release, or likely even two, and the griping from the field is going to take 3+ years to settle.
I have no desire to waste time on partial measures either though. I think I've been clear that's my theme on this--if we're gonna mess with this significantly, let's do it right and in a big way. If there's a really trivial fix to apply, that's fine too. Throw an error when the value is between the special one and the useful minimum, no other changes; that I could see slipping into a single release without much pain. Might even be possible to write as a useful sub-step toward a bigger plan too. Wouldn't bother breaking that out as a goal unless it just happened to fall out of the larger design though.
The rest of the rounding and error handling ideas wandering around seem in this uncomfortable middle ground to me. They are neither large enough to feel like a major improvement happened, nor trivial enough to apply with minimal work/risk. And this is not a bug that must be fixed ASAP--it's an unfriendly UI surprise.
-- Greg Smith greg.sm...@crunchydatasolutions.com Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
