| 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
| 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 |