Re: LATERAL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: LATERAL
Дата
Msg-id 14364.1261252910@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: LATERAL  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: LATERAL  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Aggregate ORDER BY patch
Следующее
От: Peter Eisentraut
Дата:
Сообщение: creating index names automatically?