Re: functions returning sets

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Rogers <jrogers(at)findlaw(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: functions returning sets
Date: 2003-12-16 22:58:32
Message-ID: 3FDF8E18.1080508@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> Hmm, this looks like a bug having to do with not resetting state
> correctly for the next invocation of the SRF. Hard to tell whether
> the bug is in your code or the system's support for SRFs though.

Looks like a bug in ExecScanSubPlan() around line 401:
8<-----------------------------------------------------
if (subLinkType == ANY_SUBLINK)
{
/* combine across rows per OR semantics */
if (rownull)
*isNull = true;
else if (DatumGetBool(rowresult))
{
result = BoolGetDatum(true);
*isNull = false;
break; /* needn't look at any more rows */
}
}
8<-----------------------------------------------------

If the function returns a set, that comment is wrong, isn't it? I
removed the "break" to run out all the available tuples and got the
correct result:

regression=# select id from foo where 'a' in (select
pgxml_xpath(doc,'/top/node'));
id
----
1
2
3
(3 rows)

Any guidance on the preferred fix? I don't see an obvious way to
determine if the plan includes a set returning function in
ExecScanSubPlan(), and it seems unfortunate to remove the optimization
for all other cases, especially since targetlist SRFs are deprecated.

Joe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jenny Zhang 2003-12-16 23:37:21 Re: passing array as argument and returning an array in
Previous Message Rick Gigger 2003-12-16 22:58:27 Re: add column sillyness