| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: future of PQfn() |
| Date: | 2026-05-29 15:14:29 |
| Message-ID: | ahmtVYcf4EYwz02U@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 27, 2026 at 02:39:53PM -0700, Jacob Champion wrote:
> On Tue, May 26, 2026 at 12:55 PM Nathan Bossart
> <nathandbossart(at)gmail(dot)com> wrote:
>> I wonder how difficult it would be to teach the protocol to advise clients
>> when prepared statements are deallocated...
>
> Probably not too difficult. But it seems like most, if not all, of the
> stuff in the DISCARD ALL umbrella is a target for a feature like
> that... This feels a lot like the perennial request for proxies to be
> able to separate their own context from the per-application/per-user
> contexts running on top of them.
Here is a work-in-progress patch set that goes this direction. This
introduces a callback mechanism in libpq that is used to handle statement
deallocation notifications. Older servers/clients fall back to
PQexecParams(), which is slower, but the alternative is to leave PQnfn()
and related code around indefinitely.
I'm wondering whether this new message type is general enough. For
example, perhaps we could make an extensible message type for tracking
various things. And I want to ensure this is useful for other clients,
too.
--
nathan
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-tell-client-when-prep-stmts-are-deallocated.patch | text/plain | 12.1 KB |
| v2-0002-stop-using-PQfn-in-libpq-s-LO-interface.patch | text/plain | 27.2 KB |
| v2-0003-remove-support-for-PQfn.patch | text/plain | 17.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2026-05-29 15:16:13 | Re: some utf8 breaking substring(txt,1,3) but not substring(txt from '^.{4}') |
| Previous Message | Yugo Nagata | 2026-05-29 14:14:17 | Re: Incremental View Maintenance, take 2 (design considerations) |