Re: getXXX methods

Поиск
Список
Период
Сортировка
От Kris Jurka
Тема Re: getXXX methods
Дата
Msg-id Pine.BSO.4.56.0407062020270.26570@leary.csoft.net
обсуждение исходный текст
Ответ на Re: getXXX methods  (Oliver Jowett <oliver@opencloud.com>)
Ответы Re: getXXX methods  (Oliver Jowett <oliver@opencloud.com>)
Список 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 по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: getXXX methods
Следующее
От: Oliver Jowett
Дата:
Сообщение: Re: getXXX methods