Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On Fri, Mar 10, 2017 at 11:49:46AM -0800, Andres Freund wrote:
> On 2017-03-09 13:34:22 -0500, Robert Haas wrote:
> > On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > > Andres Freund <andres(at)anarazel(dot)de> writes:
> > >> Wonder if we there's an argument to be made for implementing this
> > >> roughly similarly to split_pathtarget_at_srf - instead of injecting a
> > >> ProjectSet node we'd add a FunctionScan node below a Result node.
> > >
> > > Yeah, possibly. That would have the advantage of avoiding an ExecProject
> > > step when the SRFs aren't buried, which would certainly be the expected
> > > case.
> > >
> > > If you don't want to make ExecInitExpr responsible, then the planner would
> > > have to do something like split_pathtarget_at_srf anyway to decompose the
> > > expressions, no matter which executor representation we use.
> >
> > Did we do anything about this? Are we going to?
>
> Working on a patch.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Andres,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.

[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com