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.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/