Date: Fri, 5 Jun 2026 17:03:05 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>,
	pgsql-hackers@postgresql.org
Subject: Re: alert clients when prepared statements are deallocated
Message-ID: <aiNHmeERanDZViYv@nathan>
References: <ahm_4eOKkkKJ3Gds@nathan>
 <CAOYmi+msZYr=NhBmf-Tg3h3ZHoQjMzp-50ByFqo2A8XDKd-eHQ@mail.gmail.com>
 <CAGECzQQCKSogfz=Dqkf-+1GA13yATMu34CMU9Yqo13KXgmkW8Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAGECzQQCKSogfz=Dqkf-+1GA13yATMu34CMU9Yqo13KXgmkW8Q@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aiNHmeERanDZViYv%40nathan>
Precedence: bulk

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