Michael Hirohama <kamesan@ricochet.net> 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
