Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67]) by hub.org (8.8.8/8.7.5) with ESMTP id KAA06065; Mon, 27 Apr 1998 10:53:20 -0400 (EDT) Received: (from maillist@localhost) by candle.pha.pa.us (8.8.5/8.8.5) id KAA04993; Mon, 27 Apr 1998 10:52:44 -0400 (EDT) From: Bruce Momjian Message-Id: <199804271452.KAA04993@candle.pha.pa.us> Subject: Re: [HACKERS] Re: retrieving varchar size To: tgl@sss.pgh.pa.us (Tom Lane) Date: Mon, 27 Apr 1998 10:52:44 -0400 (EDT) Cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org In-Reply-To: <4148.893687967@sss.pgh.pa.us> from "Tom Lane" at Apr 27, 98 10:39:27 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Does what you describe actually work in the current backend? > > The problem on the libpq side is basically that the PGresult structure > is not able to represent more than one tuple descriptor. AFAICS, we can't > tamper with that without breaking all existing applications. However, > if we make the changes being discussed in this thread then it would be > a simple matter to return a *series* of PGresult structures for this > sort of query. > > Whether an application is capable of handling that is another story, > but at least the data could be passed through. > I would move forward, and see if anything breaks. If the regression tests pass, that is a good sign it works. -- 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)