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

From Peter Eisentraut
Subject Re: Refactor parse analysis of EXECUTE command
Date
Msg-id 6a9d20c5-fa8e-97fc-b548-8bac3883f57c@2ndquadrant.com
Whole thread Raw
In response to Re: Refactor parse analysis of EXECUTE command  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Refactor parse analysis of EXECUTE command  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Refactor parse analysis of EXECUTE command  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: dropdb --force
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Global temporary tables