Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)
Date
Msg-id 20170310194946.45yvbvuqz3f7b7ru@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Query fails when SRFs are part of FROM clause (Commit id:69f4b9c85f)  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On 2017-03-09 13:34:22 -0500, Robert Haas wrote:
> On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Andres Freund <andres@anarazel.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.

- Andres



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Need a builtin way to run all tests faster manner
Next
From: Jim Nasby
Date:
Subject: Re: [HACKERS] Need a builtin way to run all tests faster manner