Re: future of PQfn()

On Fri, May 29, 2026 at 08:43:07AM -0700, Jacob Champion wrote:
> On Fri, May 29, 2026 at 8:14 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> Here is a work-in-progress patch set that goes this direction.
>
> At a high level, I think advertising support for a single new message
> needs to be done in a protocol extension rather than a minor version
> bump.

WFM

>> 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.
>
> IMO there's no hurry in getting rid of that path. If we decide to go
> this direction, a fallback to PQnfn() seems like it'd fine for a few
> releases; we could eventually swap to a PQexecParams() fallback and
> get rid of the extra code once the older servers have aged out.

That's fine with me, too.

>> 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.
>
> If it's just a general notification message, what does negotiating
> "support" mean? Is best-effort notification okay, if the client has no
> idea what a future message type means, or if the server doesn't send
> the specific type of message the client is hoping for?

That's what I had in mind. But if we don't have anything specific in mind
that this mechanism could be extended to support, maybe we shouldn't
bother. Especially if we can just add protocol extensions as necessary.

> (In general, I'm kind of down on the "notify the client that X
> happened" method of working around architectural issues. Maybe that's
> what we need to move this specific part forward, but it doesn't feel
> like a long-term solution and I don't know that we need to genericize
> it without a solid set of use cases.)

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.

--
nathan