On Sat, Aug 19, 2023 at 1:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What I'm inclined to propose, therefore, is that we make revalidation
> be a no-op for every statement type for which transformStmt() reaches
> its default: case. (When it does so, the resulting CMD_UTILITY Query
> will not get any processing from the rewriter or planner either.)
> That gives us this list of statements requiring revalidation:
>
> case T_InsertStmt:
> case T_DeleteStmt:
> case T_UpdateStmt:
> case T_MergeStmt:
> case T_SelectStmt:
> case T_ReturnStmt:
> case T_PLAssignStmt:
> case T_DeclareCursorStmt:
> case T_ExplainStmt:
> case T_CreateTableAsStmt:
> case T_CallStmt:
That sounds like the right thing. It is perhaps unfortunate that we
don't have a proper parse analysis/execution distinction for other
types of statements, but if that ever changes then this can be
revisited.
--
Robert Haas
EDB: http://www.enterprisedb.com