Changed SRF in targetlist handling

On Friday, June 3, 2016, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
<javascript:_e(%7B%7D,'cvml','tgl(at)sss(dot)pgh(dot)pa(dot)us');>> wrote:

> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> > On Wed, May 25, 2016 at 3:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Andres Freund <andres(at)anarazel(dot)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.