Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
Дата
Msg-id 14138.1473972539@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)  (Andres Freund <andres@anarazel.de>)
Ответы Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Hm. One thing I wonder about with this approach, is how we're going to
> handle something absurd like:
> SELECT generate_series(1, generate_series(1, 2)), generate_series(1, generate_series(2,4));

The patch that I posted would run both the generate_series(1, 2) and
generate_series(2,4) calls in the same SRF node, forcing them to run in
lockstep, after which their results would be fed to the SRF node doing
the top-level SRFs.  We could probably change it to run them in separate
nodes, but I don't see any principled way to decide which one goes first
(and in some variants of this example, it would matter).  I think the
LATERAL approach would face exactly the same issues: how many LATERAL
nodes do you use, and what's their join order?

I think we could get away with defining it like this (ie, SRFs at the same
SRF nesting level run in lockstep) as long as it's documented.  Whatever
the current behavior is for such cases would be pretty bizarre too.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PATCH: Keep one postmaster monitoring pipe per process
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Tuplesort merge pre-reading