From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: patch for getXXX methods |
Date: | 2004-07-11 20:24:46 |
Message-ID: | 1089577486.1508.316.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Oliver,
I don't believe you will lose precision if the number is below MAX_LONG
? When I tested it on my system, I was able to retrieve a double that
was equal to MAX_LONG without losing precision.
I understand your concern about silently discarding the fractional
portion, but I also believe if the user is using this, then they know
what they are doing. Time will tell.
Dave
On Sun, 2004-07-11 at 11:04, Oliver Jowett wrote:
> Dave Cramer wrote:
> > Attached, with -cb this time
>
> Thanks. Comments:
>
> How you handle bytes and shorts is inconsistent with how you handle
> longs; we should consistently do it one way or the other. Since you lose
> precision going via a double, that probably means the BigInteger approach.
>
> The shared conversion/rangecheck logic should be done once in a helper
> function rather than duplicated -- call the helper with appropriate
> range info and cast the result.
>
> I still don't like silently discarding any fractional portion of the value.
>
> -O
>
>
>
> !DSPAM:40f15727282821451612596!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Wright | 2004-07-11 20:26:31 | JDBC Connection |
Previous Message | Dario V. Fassi | 2004-07-11 19:18:44 | Re: Timestamp Question |