Date: Fri, 29 May 2026 11:42:27 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: future of PQfn()
Message-ID: <ahnB8zuR0AYegcJI@nathan>
References: <ahXE28klgxIJXBLq@nathan>
 <CAOYmi+m3bKWfHhAj3iKBa3mKj=_4MO3xY2WpBsB4Hx7yyAE7rw@mail.gmail.com>
 <ahX6nb1aqh51IhHC@nathan>
 <CAOYmi+n6eFXs_pncObs9Vhe7S1gbvepRncYJaaO98anxL8WODg@mail.gmail.com>
 <ahmtVYcf4EYwz02U@nathan>
 <CAOYmi+mA4Cdb+RWV2M83FbsSN85t2iuoXejA-PKNrQ_ayHOQWw@mail.gmail.com>
 <ahm6kuL3L3wSYo6d@nathan>
 <CAOYmi+nhtqGZAgtLvR2OdNZ8mfdY79qseEtKXnbs1jvtLNOrZA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAOYmi+nhtqGZAgtLvR2OdNZ8mfdY79qseEtKXnbs1jvtLNOrZA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ahnB8zuR0AYegcJI%40nathan>
Precedence: bulk

For future reference in the archives, I'm moving the discussion about 0001
(the prepared statement deallocation notification mechanism) to a new
thread:

	https://postgr.es/m/ahm_4eOKkkKJ3Gds%40nathan

On Fri, May 29, 2026 at 09:33:03AM -0700, Jacob Champion wrote:
> On Fri, May 29, 2026 at 9:11 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> 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.
> 
> No worries -- I hadn't meant to block progress here on protocol
> design. I think keeping PQnfn() for the immediate future is a good
> plan. I just wanted to plant a seed for getting away from this problem
> eventually.
> 
> (As for pie-in-the-sky alternative ideas, the ability for middleware
> to separate contexts or streams of packets has come up before. libpq
> could theoretically mark its own "context" of server-side allocations
> that are not touched by an application-context DISCARD.)

Along these lines, I did consider "pinning" statements or even having
"built-in" ones for libpq.  I didn't like the "pinning" idea because that
seemed problematic for connection poolers.  And the "built-in" idea seemed
too libpq-centric for what I'd argue is a general problem.  The other ideas
involved guessing at what's happening based on the queries or somehow
trying to handle failures due to missing/wrong prepared statements, none of
which felt viable.

-- 
nathan