Robert Haas wrote: > On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane <tgl@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.
As long as someone is willing to put in the effort we can make a subset of these multiple-SRFs-in-targetlist queries work without any change in the tabular output, though the processing mechanism might change. Your vote is essentially #1 up-thread which seems the most draconian. Assuming a viable option 2.5 or 3 solution is presented would you vote against it being committed? If so I'd like to understand why. I see #1 as basically OK only if their are technical barriers we cannot overcome - including performance.
Link to the definition of the various options Tom proposed: