Date: Fri, 29 May 2026 13:29:02 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>,
	pgsql-hackers@postgresql.org
Subject: Re: alert clients when prepared statements are deallocated
Message-ID: <ahna7lre-xAn7DIS@nathan>
References: <ahm_4eOKkkKJ3Gds@nathan>
 <1689313.1780074543@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1689313.1780074543@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/ahna7lre-xAn7DIS%40nathan>
Precedence: bulk

On Fri, May 29, 2026 at 01:09:03PM -0400, Tom Lane wrote:
> 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.

Right.

> 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.

This is the intent of the callback mechanism.  In short, a libpq user could
register a callback that runs as soon as a deallocation notification is
received.  We could also add a default callback that stores a list of
deallocated prepared statements (or a subset that a caller has indicated
interest in).  Callers could then call libpq-provided functions to retrieve
and reset that list.  My hunch is that might be more convenient for
projects that use language bindings.

-- 
nathan