Re: ResultSetMetaData + CachedResultSet bug

From: Kris Jurka <books(at)ejurka(dot)com>
To: Thomas Hallgren <thomas(at)tada(dot)se>
Cc: Postgres-JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: ResultSetMetaData + CachedResultSet bug
Date: 2006-06-30 16:23:10
Message-ID: Pine.BSO.4.63.0606301117540.22707@leary2.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Guy Rouillier 2006-06-30 16:37:52 Re: Utilizing executeBatch() with stored procedures
Previous Message Thomas Hallgren 2006-06-30 08:10:00 Re: ResultSetMetaData + CachedResultSet bug