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

From Tom Lane
Subject Re: Changed SRF in targetlist handling
Date
Msg-id 24967.1464986309@sss.pgh.pa.us
Whole thread Raw
In response to Changed SRF in targetlist handling  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Friday, June 3, 2016, Tom Lane <tgl@sss.pgh.pa.us
> <javascript:_e(%7B%7D,'cvml','tgl@sss.pgh.pa.us');>> wrote:
>> Merlin Moncure <mmoncure@gmail.com> writes:
>>> another interesting case today is:
>>> create sequence s;
>>> select generate_series(1,nextval('s')), generate_series(1,nextval('s'));

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

Well, it'd be rewritten and then would fail at runtime because of the SRF
calls not producing the same number of rows.  But even option #3 would not
be strictly bug-compatible because it would (I imagine) evaluate the
arguments of each SRF only once.  The reason this case doesn't terminate
in the current implementation is that it re-evaluates the SRF arguments
each time we start a SRF over.  That's just weird ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)
Next
From: Tom Lane
Date:
Subject: Re: IPv6 link-local addresses and init data type