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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: rounding up time value less than its unit.
Date: 2014-09-26 17:22:41
Message-ID: 7639.1411752161@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-09-26 17:27:51 Re: proposal: rounding up time value less than its unit.
Previous Message Andres Freund 2014-09-26 16:32:10 Re: Replication identifiers, take 3