Re: BUG #18059: Unexpected error 25001 in stored procedure
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: paul.kulakov@systematica.ru, pgsql-hackers@lists.postgresql.org
Date: 2023-08-21T13:32:27Z
Lists: pgsql-bugs, pgsql-hackers
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
Commits
-
Avoid unnecessary plancache revalidation of utility statements.
- d8b2fcc9d4b5 17.0 landed
- ba0d737caa44 16.0 landed
- b808dbf90582 12.17 landed
- 9c59f3862b18 11.22 landed
- 9b2a41db1cc0 14.10 landed
- 8700851352a8 15.5 landed
- 27566bcf3c87 13.13 landed