On Tuesday, September 23, 2014, Tom Lane <t...@sss.pgh.pa.us> wrote: > David G Johnston <david.g.johns...@gmail.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.