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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers