Tom Lane-2 wrote > Robert Haas < > robertmhaas@
> > writes: >> I liked David Johnston's even stronger suggestion upthread: make it an >> error to specify a value requires rounding of any kind. In other >> words, if the minimum granularity is 1 minute, you can specify that as >> 60 seconds instead, but if you write 59 seconds, we error out. Maybe >> that seems pedantic, but I don't think users will much appreciate the >> discovery that 30 seconds means 60 seconds. They'll be happier to be >> told that up front than having to work it out afterward. > > I think this is totally wrong. The entire point of the GUC units system, > or at least a large part of the point, is that users should not have to > be intimately aware of the units in which a given value is measured > internally. And that in turn means that the units had better be such > that users won't find them overly coarse. If it matters a lot whether > 59 seconds gets rounded to 60, then we didn't make a good choice of units > for the GUC in question; and we should fix that choice, not mess with the > rounding rules. > > 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. To Andres' point: SELECT unit, count(*) FROM pg_settings WHERE unit <> '' GROUP BY unit; (9.3 / Ubuntu) min (1 - log_rotation_age) s (10) ms (13) kb (7) 8kb (6) I don't know about the size implications but they seem to be non-existent. That any setting critically matters at +/- 1s or 1ms doesn't seem likely in practice. Even +/- 1min for a setting, if it did matter at extreme scale, would be recognizable by the user in practice as a rounding artifact and compensated for. At this point throwing an error for any precision that results in less than the default precision is my preference. I would not change the rounding rules for the simple reason that there is no obvious improvement to be had and so why introduce pointless change that - however marginal and unlikely - will be user-visible. The complaint to overcome is avoiding an interpretation of "zero" when the precision of the input is less than the GUC unit. Lacking any concrete complaints about our round-down policy I don't see where a change there is worthwhile. Fixing zero as a special value falls under the same category. As mathematically pure as using infinity may be the trade-off for practicality and usability seems, even in light of this complaint, like the correct one to have made. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/proposal-rounding-up-time-value-less-than-its-unit-tp5811102p5816409.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
