Re: future of PQfn()
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2026-05-29T16:33:03Z
Lists: pgsql-hackers
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.) --Jacob