Tom Lane-2 wrote
> David G Johnston <
> david.g.johnston@
> > writes:
>> Tom Lane-2 wrote
>>> Indeed. I have not understood why you are insisting on "round up"
>>> semantics. Wouldn't it make more sense for the behavior to be "round to
>>> nearest"? That would get rid of any worries about treating zero
>>> specially.
>
>> Wasn't the goal that all non-zero values result in the feature being
>> enabled? With round nearest there will still be some values that are
>> non-zero but that round to zero and thus disable the feature.
>
> Ah. Okay, but then what's wrong with the original proposal of "use ceil()
> instead of floor()"? Basically I think the idea of treating fractions
> less than one differently from fractions greater than one is bogus; nobody
> will ever find that intuitive.
>
> Or we could adopt Peter's idea that zero shouldn't be special (instead
> using, say, -1 to turn things off). But I'm afraid that would break way
> too many peoples' configuration choices.
Yes, using ceil() is the most acceptable, for me, solution that does not
involve throwing an error.
Are there any examples of where treating zero specially is a problem or is
this concern theoretical? We've already decided to risk enabling disabled
features by applying this patch since the likelihood of someone relying on
the rounding to keep the feature disabled (or at its default value in some
instances) is unlikely.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/proposal-rounding-up-time-value-less-than-its-unit-tp5811102p5816018.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
