Received: from sid.trust.ee (root@sid.trust.ee [194.204.23.180]) by hub.org
	(8.8.8/8.7.5) with ESMTP id NAA08590;
	Thu, 23 Apr 1998 13:28:23 -0400 (EDT)
Received: from sid.trust.ee (wink.trust.ee [194.204.23.184])
	by sid.trust.ee (8.8.5/8.8.5) with ESMTP id UAA00300;
	Thu, 23 Apr 1998 20:27:35 +0300
Message-ID: <353F7A47.3C8D677F@sid.trust.ee>
Date: Thu, 23 Apr 1998 20:28:39 +0300
From: Hannu Krosing <hannu@trust.ee>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Hannu Krosing <hannu@trust.ee>, byronn@insightdist.com,
	pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size
References: <199804231645.MAA26157@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:
> 
> >
> > Byron Nikolaidis wrote:
> > >
> > > Hello,
> > >
> > > I was wondering if it would be possible, in the Postgres backend, to
> > > send back the defined column size for the varchar data type (and
> > > possibly the char() type, i.e., bpchar) on a query?  Currently, it just
> > > sends back -1 for the size, which makes it difficult in the frontend
> > > (i.e., odbc driver) to determine what the size of the column is.
> 
> This is kind of tough to do.

What makes it tough? 

Is this info not available where needed, or is changing the protocol
tough.

In the latter case, I would suggest an additional SQL command for open
cursors,
or a pseudo table for open cursor where you could do a simple select
statement:

DECLARE CURSOR FOO_CURSOR FOR SELECT * FROM MYTABLE;

SELECT _FIELD_NAME,_FIELD_TYPE,_FIELD_SIZE FROM
FOO_CURSOR_INFO_PSEUTOTABLE;

> > While the right solution to this is of course getting the size from
> > backend, there exists a workaround now (assuming that the query is not
> > too expensive). While ASCII cursors always hide the varchar sizes,
> > binary ones return the size in actual data (by zero-padding the
> > returned data to max size), so one can determine the actual max
> > sizes by opening the query in binary cursor and then examining
> > enough records to get one non-null field for each varchar field.
> 
> As of 6.3, this is only true of char() fields.  Varchar() is now
> variable length.

As knowing field size is quite essential for Borland applications some 
solution should be found for this.

Hannu