Horton

Re: Refactor parse analysis of EXECUTE command

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-11-08T12:34:40Z
Lists: pgsql-hackers 
On 2019-11-08 09:03, Pavel Stehule wrote:
>     Parse analysis of EXECUTE does not access any tables, so if I
>     understood
>     this correctly, this concern doesn't apply here.
> 
> 
> it should not be true - the subquery can be a expression.

Arguments of EXECUTE cannot be subqueries.

> Minimally on SQL level is not possible do prepare on execute. So execute 
> should be evaluate as one step.

Well, that's kind of the question that is being discussed in this thread.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Make better use of ParseState in ProcessUtility

  2. Add error position to an error message

  3. Do parse analysis of an EXPLAIN's contained statement during the normal

  4. First phase of plan-invalidation project: create a plan cache management