MIME-Version: 1.0
References: <ahXE28klgxIJXBLq@nathan>
 <CAOYmi+m3bKWfHhAj3iKBa3mKj=_4MO3xY2WpBsB4Hx7yyAE7rw@mail.gmail.com>
 <ahX6nb1aqh51IhHC@nathan>
 <CAOYmi+n6eFXs_pncObs9Vhe7S1gbvepRncYJaaO98anxL8WODg@mail.gmail.com>
 <ahmtVYcf4EYwz02U@nathan>
In-Reply-To: <ahmtVYcf4EYwz02U@nathan>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Fri, 29 May 2026 08:43:07 -0700
Message-ID: 
 <CAOYmi+mA4Cdb+RWV2M83FbsSN85t2iuoXejA-PKNrQ_ayHOQWw@mail.gmail.com>
Subject: Re: future of PQfn()
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BmA4Cdb%2BRWV2M83FbsSN85t2iuoXejA-PKNrQ_ayHOQWw%40mail.gmail.com>
Precedence: bulk

On Fri, May 29, 2026 at 8:14=E2=80=AFAM Nathan Bossart <nathandbossart@gmai=
l.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.

> 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