public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jacob Champion <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: [email protected]
Subject: Re: future of PQfn()
Date: Fri, 29 May 2026 08:43:07 -0700
Message-ID: <CAOYmi+mA4Cdb+RWV2M83FbsSN85t2iuoXejA-PKNrQ_ayHOQWw@mail.gmail.com> (raw)
In-Reply-To: <ahmtVYcf4EYwz02U@nathan>
References: <ahXE28klgxIJXBLq@nathan>
	<CAOYmi+m3bKWfHhAj3iKBa3mKj=_4MO3xY2WpBsB4Hx7yyAE7rw@mail.gmail.com>
	<ahX6nb1aqh51IhHC@nathan>
	<CAOYmi+n6eFXs_pncObs9Vhe7S1gbvepRncYJaaO98anxL8WODg@mail.gmail.com>
	<ahmtVYcf4EYwz02U@nathan>

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.

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

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

(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.)

--Jacob

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: <CAOYmi+mA4Cdb+RWV2M83FbsSN85t2iuoXejA-PKNrQ_ayHOQWw@mail.gmail.com>

* 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