Hi, I'm sorry for slow reaction.
I don't care whether rounding up or down it, although this title has 'rounding up'. (I just only come up with it. I'm sorry for my imprudence) I'm thinking about a method which users get quick awareness it. Now, it's okay not to change current behavior except non-zero value yields a zero. A zero rounded down from non-zero gets an error. I attached new patch. This includes a document about above behavior as Heikki suggested. regards, -------------- Tomonari Katsumata 2014-08-27 6:49 GMT+09:00 David G Johnston <david.g.johns...@gmail.com>: > 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 >
error_for_less-than_required_time-unit.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
