On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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