Horton

Re: Refactor parse analysis of EXECUTE command

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-11-08T15:20:46Z
Lists: pgsql-hackers 
pá 8. 11. 2019 v 13:34 odesílatel Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> napsal:

> 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.
>
ok

>
> > 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.
>

I say it not cleanly - I think so this change should be safe, because
parsing, transforming, and execution must be in one statement.

Regards

Pavel

>
> --
> 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