From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | Kris Jurka <books(at)ejurka(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: getXXX methods |
Date: | 2004-07-07 01:29:46 |
Message-ID: | 1089163786.1506.180.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
hmmm... Ok, just read it.
Presumably the warning would be added to the result set object?
I doubt this was the intended use as the table infers that using any of
the non-preferred methods will cast to the requested type. I do see
this as a good thing assuming the programmer is aware of the warnings,
and is handling them.
I do have one concern however: Lets suppose that the user gets a very
large result set and starts scrolling through it, we keep adding
warnings to it and we run out of memory?
Dave
On Tue, 2004-07-06 at 21:10, Oliver Jowett wrote:
> Dave Cramer wrote:
> > Oliver,
> >
> > Well as Kris pointed out the javadoc is next to useless here. I see no
> > harm in truncating the data, my assumption being that the user knows
> > what they are doing.
>
> If the application really wants silent truncation without warning can't
> they do it directly in the query?
>
> I think generating DataTruncation (nb: as a *warning*, not throwing an
> exception) is still a good idea. Then at least the application gets some
> sort of notification.
>
> Have you read the DataTruncation javadoc & spec section?
>
> -O
>
>
>
> !DSPAM:40eb4d8f105802968417614!
>
>
--
Dave Cramer
519 939 0336
ICQ # 14675561
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2004-07-07 01:38:52 | Re: getXXX methods |
Previous Message | Oliver Jowett | 2004-07-07 01:10:29 | Re: getXXX methods |