Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id KAA03373; Mon, 27 Apr 1998 10:39:49 -0400 (EDT) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.8.5/8.8.5) with ESMTP id KAA04150; Mon, 27 Apr 1998 10:39:27 -0400 (EDT) To: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org Subject: Re: [HACKERS] Re: retrieving varchar size In-reply-to: Your message of Sun, 26 Apr 1998 17:55:54 -0700 Date: Mon, 27 Apr 1998 10:39:27 -0400 Message-ID: <4148.893687967@sss.pgh.pa.us> From: Tom Lane Michael Hirohama writes: > The historical reason why the POSTGRES backend is required to send multiple > result sets is to support cursors on queries involving type inheritance and > anonymous target lists. > begin > declare c cursor for > select e.oid, e.* from EMP* e > fetch 10 in c > ... > To handle the command sequence above, frontend applications would need to > be provided with a new result descriptor when the "fetch 10 in c" crosses a > result set boundary. Hmm. I noted the place in libpq where it fails if multiple 'T' (tuple descriptor) messages arrive during a query retrieval. But the comments made it sound like the condition shouldn't occur. 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. regards, tom lane