Re: Changed SRF in targetlist handling - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Changed SRF in targetlist handling
Date
Msg-id 20160606183132.GA400162@alvherre.pgsql
Whole thread Raw
In response to Re: Changed SRF in targetlist handling  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Changed SRF in targetlist handling  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Changed SRF in targetlist handling  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Reviewing freeze map code
Next
From: Andres Freund
Date:
Subject: Re: Reviewing freeze map code