On Mon, Jun 6, 2016 at 2:31 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> 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. > 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: https://www.postgresql.org/message-id/21076.1464034513%40sss.pgh.pa.us David J.
