Skip site navigation (1) Skip section navigation (2)


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: LATERAL
Date: 2009-12-19 20:01:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-12-19 21:06:41
Subject: creating index names automatically?
Previous:From: Tom LaneDate: 2009-12-19 19:34:06
Subject: Re: Aggregate ORDER BY patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group