Re: BUG #18059: Unexpected error 25001 in stored procedure - Mailing list pgsql-hackers

From Robert Haas
Subject Re: BUG #18059: Unexpected error 25001 in stored procedure
Date
Msg-id CA+Tgmoa2dBm7=6H986FEynqv=tHdxvXt5HVYuO24TC97G4HkkA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18059: Unexpected error 25001 in stored procedure  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #18059: Unexpected error 25001 in stored procedure
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
Next
From: Önder Kalacı
Date:
Subject: Re: postgres_fdw: wrong results with self join + enable_nestloop off