MIME-Version: 1.0
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>
In-Reply-To: <ahm6kuL3L3wSYo6d@nathan>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Fri, 29 May 2026 09:33:03 -0700
Message-ID: 
 <CAOYmi+nhtqGZAgtLvR2OdNZ8mfdY79qseEtKXnbs1jvtLNOrZA@mail.gmail.com>
Subject: Re: future of PQfn()
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BnhtqGZAgtLvR2OdNZ8mfdY79qseEtKXnbs1jvtLNOrZA%40mail.gmail.com>
Precedence: bulk

On Fri, May 29, 2026 at 9:11=E2=80=AFAM Nathan Bossart <nathandbossart@gmai=
l.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.)

--Jacob