Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67]) by hub.org (8.8.8/8.7.5) with ESMTP id NAA04232; Thu, 23 Apr 1998 13:01:13 -0400 (EDT) Received: (from maillist@localhost) by candle.pha.pa.us (8.8.5/8.8.5) id MAA26157; Thu, 23 Apr 1998 12:45:42 -0400 (EDT) From: Bruce Momjian Message-Id: <199804231645.MAA26157@candle.pha.pa.us> Subject: Re: [HACKERS] Re: [INTERFACES] retrieving varchar size To: hannu@trust.ee (Hannu Krosing) Date: Thu, 23 Apr 1998 12:45:42 -0400 (EDT) Cc: byronn@insightdist.com, pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org In-Reply-To: <353F6BBC.50EB8C99@sid.trust.ee> from "Hannu Krosing" at Apr 23, 98 07:26:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > 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. > > 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. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)