Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Rushabh Lathia <rushabh.lathia@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-09T19:41:41Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?

No, and I think we should.  Is it on the v10 open items list?

			regards, tom lane

Commits

  1. Provide an error cursor for "can't call an SRF here" errors.

  2. Pass the source text for a parallel query to the workers.

  3. Move targetlist SRF handling from expression evaluation to new executor node.