Changed SRF in targetlist handling - Mailing list pgsql-hackers

From David G. Johnston
Subject Changed SRF in targetlist handling
Date
Msg-id CAKFQuwbBuCoKH3Dsk-NV8b-GkQdmWUuzoA9qCwBwEyAwVq-9HQ@mail.gmail.com
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 Friday, June 3, 2016, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Merlin Moncure <mmoncure@gmail.com> writes:
> On Wed, May 25, 2016 at 3:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> 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.
>> 2.5 would be okay with me.

> Curious if this approach will also rewrite:
> select generate_series(1,generate_series(1,3)) s;
> ...into
> select s from generate_series(1,3) x cross join lateral generate_series(1,x) s;

Yeah, that would be the idea.


Ok...  It's only a single srf as far as the outer query is concerned so while it is odd the behavior is well defined and can be transformed while giving the same result.
 
> another interesting case today is:
> create sequence s;
> select generate_series(1,nextval('s')), generate_series(1,nextval('s'));

> this statement never terminates.  a lateral rewrite of this query
> would always terminate with much better defined and well understood
> behaviors -- this is good.

Interesting example demonstrating that 100% bug compatibility is not
possible.  But as you say, most people would probably prefer the other
behavior anyhow.


If taking the 2.5 approach this one would fail as opposed to being rewritten.

This could be an exception to the policy in #3 and would be ok in #2.  It would fail in #1.

Given the apparent general consensus for 2.5 and the lack of working field versions of this form the error seems like a no brainer.

David J.

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file
Next
From: Andres Freund
Date:
Subject: Re: Perf Benchmarking and regression.