From: | Michael Nacos <m(dot)nacos(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: real -> numeric -> real result different through jdbc |
Date: | 2009-12-11 16:54:09 |
Message-ID: | 407fa4640912110854y551f47d8q6ba4acb048cdd4f9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
2009/12/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> I seem to recall hearing that JDBC fools with the extra_float_digits
> setting. The "0.60000002" looks like it probably is the actual result
> of casting 0.6 to float4 --- remember float4 is only good to about six
> decimal digits. The default display of float4 rounds off at six digits,
> but in some contexts you don't want that rounding to happen because it
> might result in losing even more precision. JDBC is being conservative
> and taking the latter approach.
>
thanks tom,
we have just discovered this setting hidden away in
ConnectionFactoryImpl.java of the JDBC sources.
surely, it's not just a case of float4 display, type casting seems to be
affected, too.
does casting use the default display or does the internal representation
change?
It is causing our regression tests, which test for equality at the SQL
level, to fail.
cheers, Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Nacos | 2009-12-11 17:22:19 | Re: real -> numeric -> real result different through jdbc |
Previous Message | Tom Lane | 2009-12-11 16:29:23 | Re: real -> numeric -> real result different through jdbc |