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

Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?

From: Віталій Тимчишин <tivv00(at)gmail(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?
Date: 2009-03-03 13:57:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
2009/3/2 DGPickett <DGPickett(at)aol(dot)com>

> 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."

I'd say it works fairly well here. It is asked a maximum, it don't know - so
it tells theoretical maximum possible and that is not precise, but correct
value. And the jisql does have a bug - it tries to allocate memory equal to
column maximum width. Imagine a varchar(1000000000) column I may use to
store long descriptions without limits (or equal PostgreSQL "text" type). My
values never larger then, say, 4KB, and jisql would try to allocate
1000000000 size buffer, that is stupid and would lead to problems. It should
have some maximum limit (say, 1MB), because even for varchar(many) column,
it usually do not have such a long values.

In response to

pgsql-jdbc by date

Next:From: Thomas KellererDate: 2009-03-03 21:07:38
Subject: Inserting into a uuid column
Previous:From: Kris JurkaDate: 2009-03-03 00:05:58
Subject: Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?

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