Skip site navigation (1) Skip section navigation (2)

Re: Correct getScale() behavior?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: dombrd(at)gmail(dot)com, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Correct getScale() behavior?
Date: 2008-05-10 00:09:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Kris Jurka <books(at)ejurka(dot)com> writes:
> On Fri, 9 May 2008, dombrd(at)gmail(dot)com wrote:
>> 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?

> Right, that change would be nice, but it would require a server change. 
> The best place to ask about that would be -hackers.  Also how do you 
> determine the precision of sum(numeric(7,2))?

The chances of anything being done about that are not measurably
different from zero.  Postgres is by and large an abstract-data-type
system that tries hard not to have too much knowledge about specific
data types, let alone specific functions for specific data types,
wired into the core server.  So even assuming that you could determine
the correct typmod to return (which, as Kris implies, you really cannot
for this example or most others), any sort of quick-hack patch to
inject the knowledge would probably be rejected.  We'd want to see it
formulated as a plugin API available to all datatypes and functions
... and the effort to do that, in comparison to the number of actual
use cases, doesn't look very promising.

			regards, tom lane

In response to

pgsql-jdbc by date

Next:From: Marco SolinasDate: 2008-05-10 17:14:13
Subject: JDBC types vs postgres types correspondation
Previous:From: Kris JurkaDate: 2008-05-09 19:45:24
Subject: Re: Correct getScale() behavior?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group