Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> This argument doesn't say anything much about which way to round for
>> values that are fractional but larger than the unit size. I'd probably
>> prefer a "round away from zero" behavior since that seems to be the most
>> consistent rule if we want to avoid silently creating zero values; but
>> I could be talked into something else.
> PeterE argued that rounding away from zero didn't make sense either
> (53F6501B.3090201@gmx.net). I feel like we're getting trapped by
> examples.
I don't find anything compelling in Peter's argument. I do agree that
if the GUC unit is hours, and the user tries to set it to 1 second or 1
microsecond, then he probably didn't understand the GUC ... but by that
argument, if the unit is hours and he tries to set it to 1.001 hours, we
should still throw an error. The point of the GUC units system is to
not be too picky about what the variable's units are, and that that should
be possible as long as the unit is small enough that the user shouldn't
care about the difference between N and N+1 units. Therefore, I am
entirely unimpressed by examples that hinge on the assumption that the
user *does* care about that; any such example can be rejected on the
grounds that it was our error to use too large a unit for that GUC.
However, as long as we have any cases with special behavior for zero,
we should expect that the user cares about the difference between 0 units
and 1 unit.
> 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.
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.
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.
regards, tom lane