Thread

Re: alert clients when prepared statements are deallocated

Nathan Bossart <nathandbossart@gmail.com> — 2026-05-29T18:29:02Z

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