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

On Tuesday, September 23, 2014, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com <javascript:;>> writes:
> > 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... :)
>
> Hey, am I not allowed to change my mind :-) ?
>
> Seriously though, the main point I was making before stands: if the
> details of the rounding rule matter, then we messed up on choosing the
> units of the particular GUC. The question is what are we going to do
> about zero being a special case.
>
> > 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.
>
> I'm not entirely sure Peter agrees; he wanted to get rid of zero being
> a special case, rather than worry about making the rounding rule safe
> for that case. But assuming that that's a minority position:
> it seems to me that adding a new error condition is more work for us,
> and more work for users too, and not an especially sane decision when
> viewed from a green-field perspective. My proposal last month was in
> response to some folk who were arguing for a very narrow-minded
> definition of backwards compatibility ... but I don't think that's
> really where we should go.
>
> regards, tom lane
>

This patch should fix the round-to-zero issue. If someone wants to get rid
of zero as a special case let them supply a separate patch for that
"improvement".

My original concern was things that are rounded to zero now will not be in
9.5 if the non-error solution is chosen. The risk profile is extremely
small but it is not theoretically zero.

David J.