| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | Jeff Rogers <jrogers(at)findlaw(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: functions returning sets |
| Date: | 2003-12-18 20:30:19 |
| Message-ID: | 24045.1071779419@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
I said:
> : Need to invent ExprContextRescan and call it at appropriate places.
> A perfectly clean solution would require being careful to reset *all*
> econtexts, which might be thought rather a lot of work to support a
> feature that's eventually going to be deprecated anyway (viz, SRFs
> outside of FROM). I'll see about the tlist-only case though.
Actually, some study shows that we *only* support set-returning
functions in ExecProject(), which is only used with the ps_ExprContext
econtext of plan nodes, which makes it pretty easy to ensure that ReScan
gets everything it needs to. I have committed a patch into 7.4 and HEAD
branches that ensures shutdown callback functions are called during
ReScan. I've tested that the problem is fixed for SQL-language
functions; for example in the regression database do
create function foo(int) returns setof int as
'select unique1 from tenk1' language sql;
and compare the output of
select foo(1) limit 10;
select unique1 from tenk1 where unique1 in (select foo(1) limit 10);
select unique1 from tenk1 where unique1 in (select foo(ten) limit 10);
These should be the same (up to ordering) but are not without the patch.
We still need a code addition that uses an ExprState shutdown callback
to reset the state of an SRF that uses the SRF_XXX macros. Joe, have
you had time to give that any thought?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2003-12-18 20:38:06 | Re: Firebird and PostgreSQL at the DB Corral. |
| Previous Message | Peter Eisentraut | 2003-12-18 20:28:51 | Re: [GENERAL] restore error - language "plperlu" is not trusted |