Skip site navigation (1) Skip section navigation (2)

Re: Column size BUG with text/bytea with 7.4 JDBC Driver (build

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: "j(dot)random(dot)programmer" <javadesigner(at)yahoo(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Column size BUG with text/bytea with 7.4 JDBC Driver (build
Date: 2004-04-10 00:48:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
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/


In response to

pgsql-jdbc by date

Next:From: Barry LindDate: 2004-04-10 00:53:33
Subject: Re: PostgreSQL 7.4.2 and pg74.1jdbc3.jar
Previous:From: David WallDate: 2004-04-10 00:32:05
Subject: Re: Connection Idle in transaction

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group