From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin Grittner <kgrittn(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Date: | 2016-09-02 14:25:16 |
Message-ID: | 20160902142516.4oarwuvqoanyoezx@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-09-02 10:20:42 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2016-09-02 09:05:35 -0500, Kevin Grittner wrote:
> >>> In general, we've been skeptical about giving any guarantees about
> >>> result ordering.
>
> > Well, it's historically how we behaved for SRFs. I'm pretty sure that
> > people will be confused if
> > SELECT generate_series(1, 10) FROM sometbl;
> > suddenly returns rows in an order that reverse from what
> > generate_series() returns.
>
> True, but how much "enforcement" do we need really? This will be a cross
> product join, which means that it can only be done as a nestloop not as a
> merge or hash (there being no join key to merge or hash on). ISTM all we
> need is that the SRF be on the inside of the join, which is automatic
> if it's LATERAL.
Right. But there's nothing to force a lateral reference to be there
intrinsically. I've added a "fake" lateral reference to the ROWS FROM
RTE to the subquery, when there's none otherwise, but that's not
entirely pretty. I'm inclined to go with that though, unless somebody
has a better idea.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-09-02 14:34:54 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Previous Message | Tom Lane | 2016-09-02 14:25:00 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |