j.random.programmer wrote:
> Hi:
>
> The latest JDBC driver (build 213) has a serious
> bug for the "COLUMN_SIZE" value, obtained via
> DBMetaData, getColumns() and then "COLUMN_SIZE.
>
> The column size returned for both bytea and text
> types is -1. (The mysql jdbc driver correctly returns
> 65535 for these binary/text column types)
>
> postgres _should_ return the max col size which
> for bytea is about 1 GB (or is it 4 GB theoretically)
> ?
>
> Either way, it certainly isn't -1
This column actually comes directly from pg_attribute.attlen on the
backend for most types; for bytea/text this appears to be always -1.
I note that JDBC only defines COLUMN_SIZE for char, date, numeric, and
decimal types, so it's not particularly portable to assume a useful
value for LONGVARBINARY columns (i.e. bytea). text columns are a bit
harder since they're not really varchar at all, but they map to
Types.VARCHAR as the closest equivalent JDBC type.
Nevertheless it'd be nice if the driver handled this better.
There are already special cases in getColumns for bpchar, varchar,
numeric, decimal, bit, and varbit. It wouldn't be hard to add a new case
for text and bytea, assuming there's a way to find an appropriate
maximum size from the backend in these cases. I'd be reluctant to
hardcode a maximum size (although I could see an argument for returning
Integer.MAX_VALUE instead of -1).
> Please fix this ASAP, I am writing an advanced
> db abstraction layer which automatically generated
> validators based on min/max column sizes.
Again, the fastest way to get this fixed is to provide a patch. The code
in question is in org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java.
-O
