On May 8, 2:33 am, bo...@ejurka.com (Kris Jurka) wrote:
> On Mon, 5 May 2008, Dave Dombrosky wrote:
> > I have looked into the driver source, and it seems like a change was
> > made in the 8.2+ drivers. When getting the result of an aggregate sum
> > (of NUMERIC(7,2) values) in 8.1 it returns -1 as the scale, but in 8.2
> > it returns 0. It looks like "-1" is meant to be taken as an undefined
> > value, which seems to be the correct behavior to me.
>
> This change was made because some ORM tools (some of the rowset stuff I
> think) pulled the scale and stored it off regardless of whether it was
> used or not. The storing code did "validation" that required it be >= 0.
> So everyone using these frameworks was screwed whether they needed the
> scale or not. So we changed it to keep them happy at the expense of
> people like used based on a size of the camps measurement alone.
I believe the relevant thread where you made the change is here:
http://groups.google.com/group/pgsql.interfaces.jdbc/browse_thread/thread/c4e6778c8663584e/920ab518bb972973
I realize I'm not going to get you to change back to returning -1 for
the scale and precision, because a lot of users would be affected by
that. However, I am wondering if there is a way we could get the
actual precision and scale returned for an aggregate sum, and other
aggregate functions as well.
I would think it should be returning a scale and precision if the
argument column has scale and precision specified, such as in the
NUMERIC(7,2) example I previously showed. It seems wrong to return 0
in this case.
I am guessing the postgresql server code would need to be changed for
that to work though. Maybe I should be suggesting this change on a
different list?
-Dave
