From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Jacob Champion <jacob.champion@enterprisedb.com>,
        pgsql-hackers@postgresql.org
Subject: Re: alert clients when prepared statements are deallocated
In-reply-to: <ahm_4eOKkkKJ3Gds@nathan>
References: <ahm_4eOKkkKJ3Gds@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Fri, 29 May 2026 11:33:37 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1689312.1780074543.1@sss.pgh.pa.us>
Date: Fri, 29 May 2026 13:09:03 -0400
Message-ID: <1689313.1780074543@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1689313.1780074543%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> When trying to take our own advice and teach the frontend LO interface to
> use prepared statements instead of PQfn(), I discovered a couple of
> problems.  The biggest problem is that clients aren't alerted when a
> prepared statement is deallocated with DISCARD or DEALLOCATE.

Of course the first question about that is "why doesn't the client
know that already ... didn't it issue the deallocate itself?".
The core answer to that question is that there might be multiple
levels of client code involved, so that while some level of the client
stack probably knows it in some way, other levels might have created
prepared statements and not be aware that they're gone.

Therefore, having the server report this is only a partial answer
to the problem: it will only directly provide a fix to the bottom
client code level.  To go further you'd need some inside-the-client
mechanism for propagating the notification up the client stack.
We can't really create that in general, but we can at least make
libpq be a responsible citizen in that chain.  In short, a proposed
fix for this must also provide a way for the calling application to
hear about these reports, and a way for it to fall back if they're
not available.

			regards, tom lane