DGPickett wrote:
> 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.
Except that the backend is not written in Java, and neither are all the
other frontends.
To some extent, this is a case of the JDBC interface not being flexible
enough about the metadata (or often not even documenting what it's meant
to mean!) - so we are stuck trying to provide the best fit we can from
the data the server gives us.
Asking the server to conform to JDBC's particular idea of how the
metadata should look, at the expense of other interfaces, seems a bit
unreasonable.
If you have a better idea about how the JDBC driver can map the
information coming from the backend to the JDBC metadata interfaces, a
patch would be great. Or you could change the calling code to
bounds-check the metadata results before it goes off and tries to
allocate the entire heap for one column in one row ..
-O