Re: alert clients when prepared statements are deallocated

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: alert clients when prepared statements are deallocated
Date: 2026-06-05 22:03:05
Message-ID: aiNHmeERanDZViYv@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 05, 2026 at 11:34:14AM +0200, Jelte Fennema-Nio wrote:
> I think I like option 2 best (and after that 1). I'm often annoyed
> that our application layer and protocol layer is so intertwined, so
> any attempt to separate them is a welcome addition in my opinion.
>
> One approach would be to:
> 1. add an optional additional text field to the Parse message as a
> kind of "namespace" for prepared statements. Leaving this field out or
> set to the empty string, would create an "application-level" prepared
> statement. Setting it to anything else would create a protocol-level
> prepared statement within that namespace. This would allow libpq to
> create its own prepared statements, without conflicting with
> protocol-level statements created by client libraries like psycopopg.
> 2. Application-level DISCARD/DEALLOCATE would not clean up these
> namespaced protocol level prepared statements
> 3. Add a protocol-level version of DEALLOCATE ALL and DISCARD ALL
> which also clean up all the protocol-level prepared statements
> 4. Add a protocol-level message to deallocate all prepared statements
> in a certain schema.

Do we need to guard who can create protocol-level statements? And if so,
how would we do that?

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-06-05 22:05:36 Re: Remove the refint contrib module (for v20)
Previous Message Okanovic, Haris 2026-06-05 21:52:58 Replace spin-wait with futex-mutex in LWLockWaitListLock() on Linux aarch64