Re: LATERAL

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