Re: proposal: rounding up time value less than its unit. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal: rounding up time value less than its unit.
Date
Msg-id 7639.1411752161@sss.pgh.pa.us
Whole thread Raw
In response to Re: proposal: rounding up time value less than its unit.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: proposal: rounding up time value less than its unit.  (Stephen Frost <sfrost@snowman.net>)
Re: proposal: rounding up time value less than its unit.  (David Johnston <david.g.johnston@gmail.com>)
Re: proposal: rounding up time value less than its unit.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> If we want the narrowest possible fix for this, I think it's "complain
> if a non-zero value would round to zero".  That fixes the original
> complaint and changes absolutely nothing else.  But I think that's
> kind of wussy.  Yeah, rounding 29 seconds down to a special magic
> value of 0 is more surprising than rounding 30 seconds up to a minute,
> but the latter is still surprising.  We're generally not averse to
> tighter validation, so why here?

So in other words, if I set "shared_buffers = 100KB", you are proposing
that that be rejected because it's not an exact multiple of 8KB?  This
seems like it's throwing away one of the fundamental reasons why we
invented GUC units in the first place.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Replication identifiers, take 3
Next
From: Stephen Frost
Date:
Subject: Re: proposal: rounding up time value less than its unit.