Re: future of PQfn()

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: future of PQfn()
Date: 2026-05-29 16:33:03
Message-ID: CAOYmi+nhtqGZAgtLvR2OdNZ8mfdY79qseEtKXnbs1jvtLNOrZA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 29, 2026 at 9:11 AM Nathan Bossart <nathandbossart(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-05-29 16:33:37 alert clients when prepared statements are deallocated
Previous Message Ashutosh Bapat 2026-05-29 16:25:10 Re: Seeking Guidance on Fixing the Cyclic RLS Policy / Infinite Recursion Bug in PostgreSQL