Skip site navigation (1) Skip section navigation (2)

Re: functions returning records

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Alex Pilosov <alex(at)pilosoft(dot)com>, Reinoud van Leeuwen <reinoud(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: functions returning records
Date: 2001-06-27 14:35:56
Message-ID: 8171.993652556@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Alex Pilosov wrote:
>> On Tue, 26 Jun 2001, Reinoud van Leeuwen wrote:
> 1: will it be possible to return multiple result sets? (in Sybase any
> select statement that is not redirected to variables or a table goes
> to the client, so it is quite common to do multiple selects). Does the
> postgresql client library support this?

>> No, libpq protocol cannot support that. This is really a sybasism, as good
>> as it is, no other database supports anything like that.

> IIRC the _protocol_ should support it all right, but the current libpq 
> implementation does not (and the sql queries in functions are not sent
> to  client either)

Actually, libpq supports it just fine too, but most clients don't.
You have to use PQsendQuery() and a PQgetResult() loop to deal with
multiple resultsets out of one query.  It is possible to see this
happening even today:

	PQsendQuery(conn, "SELECT * FROM foo ; SELECT * FROM bar");

	while ((res = PQgetResult(conn)))
	{
		...

Whether it would be a *good idea* to allow standalone SELECTs in
functions to be handled that way is another question.  I've got strong
doubts about it.  The main problem is that the function call would be
nested inside another SELECT, which means you'd have the problem of
suspending a resultset transmission already in progress.  That's *not*
in the protocol, much less libpq, and you wouldn't really want clients
forced to buffer incomplete resultsets anyway.  But it could be
supported in procedures (not functions) that are called by some kind of
PERFORM statement, so that there's not a SELECT already in progress when
they are invoked.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-06-27 14:54:20
Subject: Re: New data type: uniqueidentifier
Previous:From: Thomas T. VeldhouseDate: 2001-06-27 14:32:42
Subject: Re: Bug in createlang?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group