Re: proposal: rounding up time value less than its unit.

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(dot)g(dot)johnston(at)gmail(dot)com>:

> Tom Lane-2 wrote
> > Robert Haas &lt;
>
> > robertmhaas@
>
> > &gt; 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>