alert clients when prepared statements are deallocated

(Moving to a new thread since this seems like an independent feature.
Original discussion can be found here:
https://postgr.es/m/ahXE28klgxIJXBLq%40nathan)

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. Since this
seems like a general problem that affects more than just libpq's LO
functions, I'm seeing whether it makes sense to add some sort of
notification mechanism so that clients can re-prepare as needed. Some
initial discussion about the work-in-progress patch (which I've attached
again here) follows:

On Fri, May 29, 2026 at 11:10:58AM -0500, Nathan Bossart wrote:
> On Fri, May 29, 2026 at 08:43:07AM -0700, Jacob Champion wrote:
>> On Fri, May 29, 2026 at 8:14 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>>> Here is a work-in-progress patch set that goes this direction.
>>
>> At a high level, I think advertising support for a single new message
>> needs to be done in a protocol extension rather than a minor version
>> bump.
>
> WFM
>
>>> This
>>> introduces a callback mechanism in libpq that is used to handle statement
>>> deallocation notifications. Older servers/clients fall back to
>>> PQexecParams(), which is slower, but the alternative is to leave PQnfn()
>>> and related code around indefinitely.
>>
>> IMO there's no hurry in getting rid of that path. If we decide to go
>> this direction, a fallback to PQnfn() seems like it'd fine for a few
>> releases; we could eventually swap to a PQexecParams() fallback and
>> get rid of the extra code once the older servers have aged out.
>
> That's fine with me, too.
>
>>> I'm wondering whether this new message type is general enough. For
>>> example, perhaps we could make an extensible message type for tracking
>>> various things. And I want to ensure this is useful for other clients,
>>> too.
>>
>> If it's just a general notification message, what does negotiating
>> "support" mean? Is best-effort notification okay, if the client has no
>> idea what a future message type means, or if the server doesn't send
>> the specific type of message the client is hoping for?
>
> That's what I had in mind. But if we don't have anything specific in mind
> that this mechanism could be extended to support, maybe we shouldn't
> bother. Especially if we can just add protocol extensions as necessary.
>
>> (In general, I'm kind of down on the "notify the client that X
>> happened" method of working around architectural issues. Maybe that's
>> what we need to move this specific part forward, but it doesn't feel
>> like a long-term solution and I don't know that we need to genericize
>> it without a solid set of use cases.)
>
> I'm certainly open to other ideas, but I'm afraid this is the best I've
> come up with in my admittedly limited time thinking about the problem.

--
nathan