Robert Haas <robertmhaas@gmail.com> writes:
> I liked David Johnston's even stronger suggestion upthread: make it an
> error to specify a value requires rounding of any kind. In other
> words, if the minimum granularity is 1 minute, you can specify that as
> 60 seconds instead, but if you write 59 seconds, we error out. Maybe
> that seems pedantic, but I don't think users will much appreciate the
> discovery that 30 seconds means 60 seconds. They'll be happier to be
> told that up front than having to work it out afterward.
I think this is totally wrong. The entire point of the GUC units system,
or at least a large part of the point, is that users should not have to
be intimately aware of the units in which a given value is measured
internally. And that in turn means that the units had better be such
that users won't find them overly coarse. If it matters a lot whether
59 seconds gets rounded to 60, then we didn't make a good choice of units
for the GUC in question; and we should fix that choice, not mess with the
rounding rules.
The case where this argument falls down is for "special" values, such as
where zero means something quite different from the smallest nonzero
value. Peter suggested upthread that we should redefine any GUC values
for which that is true, but (a) I think that loses on backwards
compatibility grounds, and (b) ISTM zero is probably always special to
some extent. A zero time delay for example is not likely to work.
Maybe we should leave the rounding behavior alone (there's not much
evidence that rounding in one direction is worse than another; although
I'd also be okay with changing to round-to-nearest), and confine ourselves
to throwing an error for the single case that an apparently nonzero input
value is truncated/rounded to zero as a result of units conversion.
regards, tom lane
