public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nathan Bossart <[email protected]>
To: Jacob Champion <[email protected]>
Cc: [email protected]
Subject: Re: future of PQfn()
Date: Fri, 29 May 2026 11:10:58 -0500
Message-ID: <ahm6kuL3L3wSYo6d@nathan> (raw)
In-Reply-To: <CAOYmi+mA4Cdb+RWV2M83FbsSN85t2iuoXejA-PKNrQ_ayHOQWw@mail.gmail.com>
References: <ahXE28klgxIJXBLq@nathan>
<CAOYmi+m3bKWfHhAj3iKBa3mKj=_4MO3xY2WpBsB4Hx7yyAE7rw@mail.gmail.com>
<ahX6nb1aqh51IhHC@nathan>
<CAOYmi+n6eFXs_pncObs9Vhe7S1gbvepRncYJaaO98anxL8WODg@mail.gmail.com>
<ahmtVYcf4EYwz02U@nathan>
<CAOYmi+mA4Cdb+RWV2M83FbsSN85t2iuoXejA-PKNrQ_ayHOQWw@mail.gmail.com>
On Fri, May 29, 2026 at 08:43:07AM -0700, Jacob Champion wrote:
> On Fri, May 29, 2026 at 8:14 AM Nathan Bossart <[email protected]> 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
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: future of PQfn()
In-Reply-To: <ahm6kuL3L3wSYo6d@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox