Re: Correct getScale() behavior?
От | dombrd@gmail.com |
---|---|
Тема | Re: Correct getScale() behavior? |
Дата | |
Msg-id | 676dcb09-abab-41ba-a75d-aa25e0f62f2d@d45g2000hsc.googlegroups.com обсуждение исходный текст |
Ответ на | Correct getScale() behavior? ("Dave Dombrosky" <dombrd@gmail.com>) |
Ответы |
Re: Correct getScale() behavior?
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: