Tom Lane-2 wrote
> The case where this argument falls down is for "special" values, such as
> where zero means something quite different from the smallest nonzero
> value. Peter suggested upthread that we should redefine any GUC values
> for which that is true, but (a) I think that loses on backwards
> compatibility grounds, and (b) ISTM zero is probably always special to
> some extent. A zero time delay for example is not likely to work.
>
> Maybe we should leave the rounding behavior alone (there's not much
> evidence that rounding in one direction is worse than another; although
> I'd also be okay with changing to round-to-nearest), and confine ourselves
> to throwing an error for the single case that an apparently nonzero input
> value is truncated/rounded to zero as a result of units conversion.
Tom,
Can you either change your mind back to this opinion you held last month or
commit something you find acceptable - its not like anyone would revert
something you commit... :)
Everyone agrees non-zero must not round to zero; as long as that happens I'm
not seeing anyone willing to spending any more effort on the details.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/proposal-rounding-up-time-value-less-than-its-unit-tp5811102p5820024.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.