Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?

On Feb 26, 3:54 pm, bo...@ejurka.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:
>
> http://archives.postgresql.org/pgsql-jdbc/2008-05/msg00021.php
>
> 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...@postgresql.org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-jdbc

Yes, I see it comes up over and over:

http://archives.postgresql.org/pgsql-hackers/2007-06/msg00428.php

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.