On Fri, May 29, 2026 at 01:09:03PM -0400, Tom Lane wrote: > Nathan Bossart <[email protected]> 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
