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

Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?

From: DGPickett <DGPickett(at)aol(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?
Date: 2009-02-27 17:41:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
On Feb 26, 3:54 pm, bo(dot)(dot)(dot)(at)ejurka(dot)com (Kris Jurka) wrote:
> On Thu, 26 Feb 2009, DGPickett wrote:
> > Well, can the JDBC team raise this issue with the postgres server
> > team, that many relatively obvious cases are being marked 'width
> > unknown'?
> They are aware.  See this previous discussion regarding the same problem
> with numeric types:
> You can take it up on pgsql-hackers if you want, but unless you have
> something conrete to add, I wouldn't bother.
> Kris Jurka
> --
> Sent via pgsql-jdbc mailing list (pgsql-j(dot)(dot)(dot)(at)postgresql(dot)org)
> To make changes to your subscription:

Yes, I see it comes up over and over:

The discussions about char versus byte were nice, but the method name
says "Display" and the api doc says "characters", so if you have
Nvarchar(20) in a 16 bit unicode context, the storage needs 40 bytes
(plus a length) and the right return is 20.  Nobody expects or wants
the gratuitous expense of dynamic sizing, just the obvious max so they
can typeset text output.  JAVA hides the code for wide characters, and
we do not want it bring it back into the light.

Somehow, doing what the real money RDBMS do, the de-facto standard, is
hard for postgres dudes, or they have more important concerns.  It
makes the product seem shabby by comparison.  Usually, that is enough
to motivate frantic coding, to make open source appear just as good.

In response to


pgsql-jdbc by date

Next:From: DGPickettDate: 2009-02-28 20:11:20
Subject: Re: SQL scipts parser
Previous:From: Dave CramerDate: 2009-02-27 15:22:49
Subject: Re: SQL scipts parser

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