From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "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 18:27:09 |
Message-ID: | 20140926182709.GX16422@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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.
Right, agreed.
> 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.)
+1
> 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.
Yes.
> 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.
Agreed- they're independent considerations and the original concern was
about the nonzero-to-zero issue, so I'd suggest we address that first,
though in doing so we will need to consider what *actual* min values we
should have for some cases which currently allow going to zero for the
special case and that, I believe, makes this all 9.5 material and allows
us a bit more freedom in deciding how to hanlde things more generally.
As such, I'd also +1 the "round-to-nearest" suggestion as being quite
sensible too.
THanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-09-26 18:33:53 | Re: proposal: rounding up time value less than its unit. |
Previous Message | David Johnston | 2014-09-26 18:18:27 | Re: proposal: rounding up time value less than its unit. |