Hi, > On 25 Sep 2026, at 16:33, Tom Lane <[email protected]> wrote: > > I'm not convinced by this blithe assertion "not our business to raise > error". The adjacent case for ExecuteStmt *will* raise an error if > it can't find the prepared statement; why shouldn't this case act like > that one? IOW, the sequence of client operations that you show is > invalid, and I think we ought to push back on that accordingly.
Alright, here is a patch that now explicit returns an error when the portal is already closed, matching what ExecuteStmt does. -- Cheers, Dirkjan
v2-0001-Fix-crash-when-describing-a-FETCH-statement-wh.patch
Description: Binary data
