Re: Changed SRF in targetlist handling

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Changed SRF in targetlist handling
Дата
Msg-id 20160525203257.tletadlmq3qa4qsx@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Changed SRF in targetlist handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Changed SRF in targetlist handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2016-05-25 15:20:03 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2016-05-25 15:02:23 -0400, Tom Lane wrote:
> >> [ shrug... ]  That seems like it's morally equivalent to (but uglier than)
> >> what I wanted to do, which is to teach the planner to rewrite the query to
> >> put the SRFs into a lateral FROM item.  Splitting the tlist into two
> >> levels will work out to be exactly the same rewriting problem.
> 
> > I think that depends on how bug compatible we want to be. It seems
> > harder to get the (rather odd!) lockstep iteration behaviour between two
> > SRFS with the LATERAL approach?
> 
> We could certainly make a variant behavior in nodeFunctionscan.c that
> emulates that, if we feel that being exactly bug-compatible on the point
> is actually what we want.  I'm dubious about that though, not least
> because I don't think *anyone* actually believes that that behavior isn't
> broken.  Did you read my upthread message suggesting assorted compromise
> choices?

You mean https://www.postgresql.org/message-id/21076.1464034513@sss.pgh.pa.us ?
If so, yes.

If we go with rewriting this into LATERAL, I'd vote for 2.5 (trailed by
option 1), that'd keep most of the functionality, and would break
visibly rather than invisibly in the cases where not.

I guess you're not planning to work on this?

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_bsd_indent - improvements around offsetof and sizeof
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Changed SRF in targetlist handling