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

Re: [RFC] Set Returning Functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] Set Returning Functions
Date: 2002-04-30 13:58:43
Message-ID: 19778.1020175123@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> 5. Ignore the current code which allows functions to return multiple
>> results as expressions; we can leave it there, but deprecate it with the
>> intention of eventual removal.

> What does the current 'setof' pl/pgsql business actually _do_?

plpgsql doesn't handle setof at all, AFAIR.  SQL-language functions do.
The gold is hidden in src/backend/executor/*.c.  The SQL function
executor (functions.c) suspends the query plan for the function's final
SELECT, and re-executes it to get one more result row each time it's
re-called.  That's okay as far as it goes; but look at what happens when
such a function is called from a SELECT targetlist.

The ExprMultipleResult flag from the function propagates up through
execQual.c, to ExecTargetList which forms a new result tuple for each
function result.  All the node executor routines that call ExecProject
have to be prepared to deal with that (eg, first if() in ExecScan).

This is all really messy, both in the implementation and in the
conception IMHO; for example, the behavior with multiple SRFs in the
same targetlist is really pretty stupid (and it was worse when the
code left Berkeley).  I'd like to deprecate and eventually remove the
whole feature.  SRFs in FROM (as table sources) make way more sense
than SRFs in targetlists.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Karel ZakDate: 2002-04-30 14:26:55
Subject: Re: Syscache/relcache invalidation event callbacks
Previous:From: Tom LaneDate: 2002-04-30 13:43:29
Subject: Re: Syscache/relcache invalidation event callbacks

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