Re: getXXX methods - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: getXXX methods
Date
Msg-id Pine.BSO.4.56.0407062020270.26570@leary.csoft.net
Whole thread Raw
In response to Re: getXXX methods  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: getXXX methods
List pgsql-jdbc

On Wed, 7 Jul 2004, Oliver Jowett wrote:

> 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?
>

It makes sense to me on the write side where a database could truncate
data to a varchar(N) column instead of erroring, but pg considers this and
numeric out of range values as errors.  On the read side assuming that the
user "knows what they are doing" seems wrong.  Consider a likely situation
like a int8 column value being retrieved with getInt(), it works fine for
years, but once hitting the limit on integer size a truncation would
cause bizarre application errors.

Section 8.3.1 of the spec clearly seems to indicate that a silent
truncation is a special case and that shouldn't be our behavior for other
data types than those specifically affected by setMaxFieldSize().  The
DataTruncation API is organized around byte sizes and just doesn't seem
right for numeric data.  Even if the spec does imply that a warning
shuold be issued (which is not clear to me), I can't imagine why
anyone would want this.  If I want truncation I'll do it myself, otherwise
I want any error to immediately raise a red flag and put the brakes on
processing.  How many people really check for warnings anyway?

Kris Jurka

pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: getXXX methods
Next
From: Oliver Jowett
Date:
Subject: Re: getXXX methods