On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Oh. Yeah. > 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. What is the best place to look for the existing, rather crocky code? I have to admit that the whole mechanism by which paths get transformed into plans and handed off to the executor is still rather opaque to me. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
