Date: Tue, 26 May 2026 11:05:47 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: pgsql-hackers@postgresql.org
Subject: future of PQfn()
Message-ID: <ahXE28klgxIJXBLq@nathan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://www.postgresql.org/message-id/ahXE28klgxIJXBLq%40nathan>
Precedence: bulk

PQfn() was marked "somewhat obsolete" in commit efc3a25bb0 (2003), and was
later marked "unsafe" in commit bd48114937 (2026).  I looked around for
third-party code that uses this interface but found none, and the only
internal usage is for the frontend LO interface.  As part of the latter
commit, a special PQnfn() function was added for use by the fronend LO
functions, but this was not exported by libpq.

Given the above, I'd like to propose retiring PQfn() in v20.  Since it's an
exported symbol, we can't just delete the code, but we could have it
unconditionally error.  Assuming folks are okay with that, I'm wondering
what we should do with the relevant documentation.  Should we leave a stub
with a note about its removal, or should we just wipe all mentions?  I'm
currently leaning towards leaving a note, but I could see the argument
that's not even worth doing given the lack of uptake.

The other question is what to do with the frontend LO code.  The simplest
thing we can do is to leave PQnfn() around as an internal function that is
only used by this interface.  Alternatively, we could take our own advice
and used a prepared statement with binary transmission of params/results,
but that has two key problems: 1) potential name collisions with
user-created prepared statements and 2) breakage after DISCARD/DEALLOCATE,
which I haven't come up with a good way to deal with.  Another approach we
could take is to just send the query via PQexecParams(), but a simple test
(creating and unlinking 10K LOs) showed a ~41% slowdown compared to HEAD.
So, I guess we'll need to keep PQnfn() around for now...

Thoughts?

-- 
nathan