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
