On Sat, Aug 19, 2023 at 1:19 PM Tom Lane <t...@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
