Robert Haas wrote: > On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would > >>> have the same behavior as before if the SRFs all return the same number > >>> of rows, and otherwise would behave differently. > > > >> I thought the idea was to rewrite it as LATERAL ROWS FROM (srf1()), > >> LATERAL ROWS FROM (srf2()), ... > > > > No, because then you get the cross-product of multiple SRFs, not the > > run-in-lockstep behavior. > > Oh. I assumed that was the expected behavior. But, ah, what do I know?
Lots, I assume -- but in this case, probably next to nothing, just like most of us, because what sane person or application would be really relying on the wacko historical behavior, in order to generate some collective knowledge? However, I think that it is possible that someone, somewhere has two SRFs-in-targetlist that return the same number of rows and that the current implementation works fine for them; if we redefine it to work differently, we would break their application silently, which seems a worse problem than breaking it noisily while providing an easy way forward (which is to move SRFs to the FROM list) My vote is to raise an error in the case of more than one SRF in targetlist. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers