Robert Haas <robertmh...@gmail.com> writes:
> Incidentally, the reason why the executor chokes trying to execute a
> SRF with an outer reference is because ExecEvalVar() craps out trying
> to dereference a null TupleTableSlot. If I'm understanding this
> correctly, that, in turn, happens because the variable that we're
> trying to deference is marked as neither INNER nor OUTER, so it's
> assumed to be from a scan, but there's no scan node. Going even
> further from my area of actually understanding what's going on, I
> think this needs to be fixed by adjusting setrefs.c.
Well, no: we can't handle such references as OUTER vars because the
OUTER slot is likely to be in use already in the sub-join. It would be
even messier if you wanted several references to different outer
relations.
I believe the correct approach is probably to treat values that need to
be propagated into the inner side as executor parameters. This could
replace the existing, rather crocky, management of values passed into a
nestloop inner indexscan. The mechanisms that deal with forcing rescans
of subplans affected by a changed parameter value would be very helpful
here too.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
