Thread: 7.4 driver vs 8.2 driver

7.4 driver vs 8.2 driver

From
ismo.tuononen@solenovo.fi
Date:
Hi,

we have problem with our 8.2 database. we use jdbc driver to connect to
database.

query

select trunc($1,2);
and that $1 is binded to double precision

works with pg74.216.jdbc3.jar driver but with postgresql-8.2-504.jdbc4.jar
we get error:

ERROR:  function round(double precision, integer) does not exist at
character 26
HINT:  No function matches the given name and argument types. You may need
to add explicit type casts.

to change all queries to:
select
trunc(to_number(to_char($1,'99999999999999.999999),'99999999999999.999999');

is just stupid and takes very long time, because it must be done manually
(queries are in reality much more complex)

any ideas what to do?

is it best to stay in 7.4 database?

I just don't understand why postgresql dont have trunc(double
precision,int) when it have trunc(double precision),trunc(numeric) and
trunc(numeric,int)

Ismo

Re: 7.4 driver vs 8.2 driver

From
Heikki Linnakangas
Date:
ismo.tuononen@solenovo.fi wrote:
> select trunc($1,2);
> and that $1 is binded to double precision
>
> works with pg74.216.jdbc3.jar driver but with postgresql-8.2-504.jdbc4.jar
> we get error:
>
> ERROR:  function round(double precision, integer) does not exist at
> character 26
> HINT:  No function matches the given name and argument types. You may need
> to add explicit type casts.
>
> to change all queries to:
> select
> trunc(to_number(to_char($1,'99999999999999.999999),'99999999999999.999999');
>
> is just stupid and takes very long time, because it must be done manually
> (queries are in reality much more complex)
>
> any ideas what to do?

You can use a cast: select trunc(($1)::numeric).

> I just don't understand why postgresql dont have trunc(double
> precision,int) when it have trunc(double precision),trunc(numeric) and
> trunc(numeric,int)

trunc(double precision, int) wouldn't make much sense. The value would
be given in base 2 floating point format, while the precision would be
given as a number of *decimal* places, IOW base 10. If you find that you
need to do that, you should reconsider the data types you use.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com