* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > Here's another proposal- how about we support a 'minimum-if-not-zero'
> > option for GUCs more generally, and then throw an error if the user sets
> > the value to a value below that minimum unless they explicitly use zero
> > (to indicate whatever the special meaning of zero for that GUC is)?
>
> I don't think that the extra complexity in that is worth the effort.
Alright.
> You could maybe talk me into "round to nearest, and then complain if that
> produced zero from nonzero" (in effect, your proposal with the minimum
> always exactly half a unit). But that seems like mostly extra complexity
> and an extra error case for not much. Again, *the user shouldn't care*
> what our rounding rule is exactly; if he does, it means the particular
> GUC was misdesigned.
I agree that the user shouldn't have to care, and I agree with your
earlier comment on this thread that having the rounding rules be
different when near zero vs. not-near-zero could be quite confusing.
> We could adopt a straightforward "round to nearest" rule if we changed
> things around enough so that zero was never special, which I think is
> what Peter was really arguing for in the post you cite. But that strikes
> me as a large amount of work, and a large loss of backwards compatibility,
> in return for (again) not much.
Agreed- I'm a bit concerned about backwards compatibility for all of the
proposals which change the existing rounding rules, but, if the
consensus is that N vs. N+1 shouldn't actually matter for values of
N < X < N+1 (as a one-unit step should be small enough to be not
terribly noticeable), then perhaps we can still move forward with the
ceil() approach as that looks to be the only argument against it.
To clarify- we'll simply swap from (essentially) floor() to ceil() for
handling all GUC_with_unit to internal_unit conversions, document that,
and note it in the release notes as a possible behavior change and move
on.
Thoughts? Objections?
Thanks!
Stephen