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

Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?

From: Kris Jurka <books(at)ejurka(dot)com>
To: DGPickett <DGPickett(at)aol(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org, David(dot)Pickett(at)nasdaqomx(dot)com
Subject: Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?
Date: 2009-02-26 00:11:50
Message-ID: Pine.BSO.4.64.0902251858180.2899@leary.csoft.net (view raw or flat)
Thread:
Lists: pgsql-jdbc

On Wed, 25 Feb 2009, DGPickett wrote:

> Selecting a constant string or concatenated columns from postgres
> using jisql (xigole), I get heap overflow.
>
> select 'X' AS XXX from . . . .

While in this case it's obvious that 'X' has length 1, the server isn't 
telling the driver that.  Even if it did in this case, there are clearly 
cases the server cannot know the output length.  Consider:

SELECT repeat('X', (random() * 100)::int);

So regardless of the simple case you've shown, we must be able to handle 
unknown length data.  Previously we did that by returning -1 which broke 
the rowset implementation which insisted that the value by >= 0.  So we 
moved to Integer.MAX_VALUE which seems to mostly work for people.

This thread details how we intend to solve the similar problem of 
getPrecision for Crystal Reports users, so we could likely apply the same 
sort of changes for display size as well.

http://archives.postgresql.org/pgsql-jdbc/2008-12/msg00018.php

> This discussion seems to say this is a postgres JDBC bug:
>
> http://forums.hotjoe.com/posts/list/315.page
>

That's not how I read the discussion.  The thread says that h2 does the 
same thing and that the author has provided a workaround to allow the user 
to provide a custom formatter to handle data types with problems.

Kris Jurka

In response to

Responses

pgsql-jdbc by date

Next:From: DGPickettDate: 2009-02-26 16:54:11
Subject: Re: ResultSetMetaData.getColumnDisplaySize returns 2147483647 ?
Previous:From: Jesus MaudesDate: 2009-02-26 00:05:22
Subject: Early JDBC driver load?

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