Re: ResultSetMetaData + CachedResultSet bug

Поиск
Список
Период
Сортировка
Искать
От
Kris Jurka
Тема
Re: ResultSetMetaData + CachedResultSet bug
Дата
Msg-id
Pine.BSO.4.63.0606291837350.28844@leary2.csoft.net
Ответ на
Список
Дерево обсуждения
ResultSetMetaData + CachedResultSet bug "Sergii Sinelnychenko" <SSinelnychenko@bossdev.com>
Re: ResultSetMetaData + CachedResultSet bug Kris Jurka <books@ejurka.com>
Re: ResultSetMetaData + CachedResultSet bug Thomas Hallgren <thomas@tada.se>
Re: ResultSetMetaData + CachedResultSet bug Kris Jurka <books@ejurka.com>
Re: ResultSetMetaData + CachedResultSet bug Kris Jurka <books@ejurka.com>


On Thu, 22 Jun 2006, Sergii Sinelnychenko wrote:

>   Today I have found a strange bug in JDBC driver (I used the last version 
> avilable - 8.2dev-503). The problem is with VARCHAR fields - driver returns 
> "-1" on "getPrecision()" call. But class javax.sql.rowset.RowSetMetaDataImpl 
> in its "setPrecision()" method requires values of 0 and more (javadoc sais 
> "precision the total number of decimal digits; must be 0 or more 
> ").
> I understand that in case of VARCHAR type we cannot speak about real number 
> of decimal digits - but could just driver return 0 instead of -1?


That certainly looks like a reasonable thing to do for text types.  The 
one case that needs a little more thinking about is a numeric field that 
has neither precision nor scale supplied.  For this we currently return -1 
for both precision and scale.  The maximum precision of a numeric is 1000 
digits, so we could divy it up evenly and make an unadorned numeric be 
returned as numeric(1000,500), but that seems a little too much like just 
making things up.  Thoughts?

Kris Jurka
В списке pgsql-jdbc по дате отправления
От: Kris Jurka
Дата:
Сообщение: Re: Italian translation update
От: Thomas Hallgren
Дата:
FAQ