| 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
| 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 |