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

From Tom Lane
Subject Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
Date
Msg-id 11652.1485820490@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Subtle bug in "Simplify tape block format" commit
Next
From: David Rowley
Date:
Subject: Re: [HACKERS] Performance improvement for joins where outer side is unique