Re: RETURN QUERY in PL/PgSQL?

From: Neil Conway <neilc(at)samurai(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, andrew(at)dunslane(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us, josh(at)agliodbs(dot)com
Subject: Re: RETURN QUERY in PL/PgSQL?
Date: 2007-04-24 18:40:49
Message-ID: 1177440049.16415.230.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2007-04-24 at 07:58 +0200, Pavel Stehule wrote:
> It is RETURN TABLE(SQL) via ANSI SQL 2003

I think there are two basically orthogonal features in the patch: the
"RETURNS TABLE" addition to CREATE FUNCTION, and the "RETURN TABLE"
statement in PL/PgSQL. The former is specified by the SQL standard and
is applicable to all PLs, while the latter is syntax sugar for PL/PgSQL.
I think it would make sense to split the patch into two separate
patches, one for each feature.

I'm inclined to agree with Tom that adding PROARGMODE_TABLE isn't worth
the trouble: making RETURNS TABLE(...) equivalent to RETURNS SETOF
RECORD with OUT parameters strikes me as more elegant. I didn't really
understand the "name collision" argument you made earlier[1]; can you
elaborate?

Another question is how RETURN NEXT and RETURN TABLE should interact (in
PL/PgSQL). I think the two sensible choices are to either disallow a
function from using both statements (which is what the patch currently
does), or allow both statements to be used, and have RETURN TABLE *not*
return from the function -- both RETURN TABLE and RETURN NEXT would
append results to the function's result tuplestore. The latter seems
more flexible.

Do we need the extra set of parentheses in RETURN TABLE? To use one of
your earlier examples:

CREATE FUNCTION fooff(a int)
RETURNS TABLE(a int, b int) AS $$
BEGIN
RETURN TABLE(SELECT * FROM Foo WHERE x < a);
END; $$ LANGUAGE plpgsql;

"RETURN TABLE SELECT ... ;" should be sufficient to allow correct
parsing, and is more consistent with the lack of parentheses in the
other RETURN variants.

-Neil

[1] http://archives.postgresql.org/pgsql-patches/2007-04/msg00311.php

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2007-04-24 18:57:28 Re: Patch for monitoring.sgml
Previous Message Peter Eisentraut 2007-04-24 18:23:12 Re: UNION with more than 2 branches