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
|
Список | 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 по дате отправления: