Re: Changed SRF in targetlist handling
От | Tom Lane |
---|---|
Тема | Re: Changed SRF in targetlist handling |
Дата | |
Msg-id | 24967.1464986309@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Changed SRF in targetlist handling ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | 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 по дате отправления: