Re: future of PQfn()

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

In response to

Responses

Browse pgsql-hackers by date

  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)