Re: proposal: rounding up time value less than its unit.

David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I apparently have got to make this point one more time: if the user
>> cares about the difference between 30sec and 1min, then we erred in
>> designing the GUC in question; it should have had a smaller unit.
>> I am completely not impressed by arguments based on such cases.
>> The right fix for such a case is to choose a different unit for the GUC.

> You are right - both those values are probably quite stupid to set
> log_rotation_age to...but we cannot error if they choose "1min"

I've been thinking more about this, and I think I'm about ready to
change my position on it: why shouldn't we error out if the value
is too small? If we believe that a GUC's unit is reasonably chosen,
then it's not sensible to try to set the value to less than 1 unit.
If the user tries then there's fairly good reason to assume that
either it's a typo or he fundamentally doesn't understand the GUC.
(This does not imply that he cares about the difference between
9999 and 9999.4 units.)

Or another way to say it is that if we had set the min_val to something
positive, he'd have gotten a "value out of range" type of error.
The only reason we don't do that, typically, is that we're allowing
zero as a special case. Well, ok, let's allow zero as a special case,
but it has to be written as "0" not something else. If you try to
set a positive value then we should act as though the min_val is 1 unit.

So I'm coming around to the idea that "throw an error if a nonzero
input would round (or truncate) to zero" is a reasonable solution.
I think it'd be even more reasonable if we also fixed the rounding
rule to be "round to nearest", but the two changes can be considered
independently.

regards, tom lane