Re: Changed SRF in targetlist handling - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Changed SRF in targetlist handling
Date
Msg-id 20160525203257.tletadlmq3qa4qsx@alap3.anarazel.de
Whole thread Raw
In response to Re: Changed SRF in targetlist handling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Changed SRF in targetlist handling  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_bsd_indent - improvements around offsetof and sizeof
Next
From: Tom Lane
Date:
Subject: Re: Changed SRF in targetlist handling