Re: Refactor parse analysis of EXECUTE command - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Refactor parse analysis of EXECUTE command
Date
Msg-id CAFj8pRAG6EiRZG7djmQ6DfqSHJ9789zs7MzXEgz2+BV3TMfgfw@mail.gmail.com
Whole thread Raw
In response to Re: Refactor parse analysis of EXECUTE command  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List 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

pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: Monitoring disk space from within the server
Next
From: Pavel Stehule
Date:
Subject: Re: Why overhead of SPI is so large?