Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) |
Дата | |
Msg-id | CA+TgmobpvpfvN6QvFSM6KMGS=miecxk1mpTTqAdhkmfxrME2+g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f) |
Список | pgsql-hackers |
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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: