Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?

On Mar 2, 4:10 am, oli(dot)(dot)(dot)(at)opencloud(dot)com (Oliver Jowett) wrote:
> 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 ..

If you have to change calling code to access Postgres, it violates the
original promise of JDBC: use me and be portable. If you want an 'I
don't know' response built into this API method, sell it to the JDBC
community, but until then, it is a requirement. Most RDBMS have not
stumbled when delivering on the requirement, so selling it as a
hardship seems difficult. As the real estate zoning lawyers say,
"This is, at best, a self-imposed hardship."

Re: Character / Byte, I know that in addition to 1, 2 and 4 byte wide
characters of several families, we have these variable width creatures
like UTF-8. RDBMS developers can hardly be happy about complications
of this development, but to stay on the road to being more and more
application-facing, they should provide storage in characters for any
sort of character, even if the underlying storage must be overly
generous or variable to accommodate this. JAVA and JDBC are just
leading the way. When this call is made, they should be able to say
how many characters are configured for the result set column. Just as
when smallint + int is typed up to int (bigint would be safer) to hold
the result and all the smallint values are cast up, when "X" || zzz (a
column varchar(10)) is parsed, the result should be typed varchar(11)
or char(11). The RDBMS should provide this metadata from its parsing
process to JDBC.