public inbox for [email protected]  

help / color / mirror / Atom feed

From: Nathan Bossart <[email protected]>
To: Tom Lane <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: [email protected]
Subject: Re: alert clients when prepared statements are deallocated
Date: Fri, 29 May 2026 13:29:02 -0500
Message-ID: <ahna7lre-xAn7DIS@nathan> (raw)
In-Reply-To: <[email protected]>
References: <ahm_4eOKkkKJ3Gds@nathan>
	<[email protected]>

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

view thread (13+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: alert clients when prepared statements are deallocated
  In-Reply-To: <ahna7lre-xAn7DIS@nathan>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox