From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Changed SRF in targetlist handling |
Date: | 2016-06-03 20:38:29 |
Message-ID: | 24967.1464986309@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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:
>>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-03 21:02:28 | Re: IPv6 link-local addresses and init data type |
Previous Message | Robert Haas | 2016-06-03 20:23:19 | Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan) |