From: | Craig Longman <craigl(at)begeek(dot)com> |
---|---|
To: | pgsql-jdbc <pgsql-jdbc(at)postgresql(dot)org> |
Cc: | Dave Cramer <Dave(at)micro-automation(dot)net> |
Subject: | Re: more incorrect values for DatabaseMetaData.getColumns() |
Date: | 2002-06-10 15:14:26 |
Message-ID: | 1023722067.3802.20.camel@jigra.begeek.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Mon, 2002-06-10 at 09:32, Dave Cramer wrote:
> Does anybody know what the definitive answer is here?
i'm basing my assertion that the pgsql interpretation is mistaken on the
docs from the jdk 1.1 api. the DatabaseMetaData.getColumns() describes
the ResultSet returned, and column #7 is the COLUMN_SIZE, it says this:
7. COLUMN_SIZE int => column size. For char or date types, this
is the maximum number of characters, for numeric or decimal types
this is precision.
as seen at:
http://java.sun.com/products/jdk/1.1/docs/api/java.sql.DatabaseMetaData.html
so, i don't know if '26' is the right answer for the length of the dates
in pgsql, but i do know its longer than 8.
in some ways, i think the pgsql answer makes more sense (returning
storage space), but it is definitely not the same information that the
other databases return for this column.
> On Sat, 2002-06-08 at 10:21, Craig Longman wrote:
> >
> > just also noticed that the date values are coming back with a
> > COLUMN_SIZE of 8 (again, storage i guess?) whereas the other databases
> > are coming back with 26.
--
CraigL->Thx();
Be Developer ID: 5852
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-06-10 16:15:48 | Re: more incorrect values for DatabaseMetaData.getColumns() |
Previous Message | Dave Cramer | 2002-06-10 13:32:57 | Re: more incorrect values for DatabaseMetaData.getColumns() |