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
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 |