Re: ResultSetMetaData + CachedResultSet bug - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: ResultSetMetaData + CachedResultSet bug
Date
Msg-id Pine.BSO.4.63.0606301117540.22707@leary2.csoft.net
Whole thread Raw
In response to Re: ResultSetMetaData + CachedResultSet bug  (Thomas Hallgren <thomas@tada.se>)
List pgsql-jdbc

On Fri, 30 Jun 2006, Thomas Hallgren wrote:

> I think the current -1 is reasonable for non numeric types. For the numeric
> types however, the interpretation should be that 0 is unlimited. A numeric
> should never return -1 and should accept setPrecision(colidx, 0) as 'no
> limit', i.e.
>
> 0 = unlimited
> -1 = not applicable
>
> A setPrecision call on types where precision has no meaning should IMO yield
> an exception.
>
> The rationale is that a) stating that a varchar has zero decimal digits is
> wrong since it doesn't have any notion of decimal digits, and b) a precision
> of zero for a numeric doesn't make sense when interpreted verbatim.

I'm not sure what the harm in using zero for text types' precision is.
Yes, I agree it'd be best if all applications were smart enough to use the
type information correctly, but they're not.  Especially when it's
something in the standard JDK that everyone uses I think we should try to
work around it if we can.

What about scale for an unspecified numeric?  zero is a legitimate scale
so that can't be used for unlimited, but RowSetMetaDataImpl doesn't like
anything < 0.

Kris Jurka

pgsql-jdbc by date:

Previous
From: Yukino Miyazawa
Date:
Subject: Utilizing executeBatch() with stored procedures
Next
From: "Guy Rouillier"
Date:
Subject: Re: Utilizing executeBatch() with stored procedures