Re: Nathan Bossart > 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
I found some references via Debian's codesearch: https://sources.debian.org/src/fpc/3.2.2+dfsg-50/fpcsrc/packages/postgres/src/postgres3dyn.pp?hl=141#L141 PQfn : function (conn:PPGconn; fnid:longint; result_buf:Plongint; result_len:Plongint; result_is_int:longint;args:PPQArgBlock; nargs:longint):PPGresult;cdecl; { Accessor functions for PGresult objects } https://sources.debian.org/src/clisp/1:2.49.20250504.gitf662209-2/modules/postgresql/postgresql.lisp?hl=375#L375 ;; "Fast path" interface --- not really recommended for application use (def-call-out PQfn (:return-type PGresult) (:arguments (conn PGconn) (fnid int) (result_buf (c-ptr int) :out) (result_len (c-ptr int) :out) (result_is_int int) (args (c-array-ptr PQArgBlock)) ; at least nargs (nargs int))) https://sources.debian.org/src/rust-pq-sys/0.7.5-1/src/bindings_linux_32.rs?hl=745#L745 unsafe extern "C" { pub fn PQfn( conn: *mut PGconn, fnid: ::std::os::raw::c_int, result_buf: *mut ::std::os::raw::c_int, result_len: *mut ::std::os::raw::c_int, result_is_int: ::std::os::raw::c_int, args: *const PQArgBlock, nargs: ::std::os::raw::c_int, ) -> *mut PGresult; } https://sources.debian.org/src/vala/0.56.19-1/vapi/libpq.vapi?hl=349#L349 [CCode (cname = "PQfn")] public Result fn (int fnid, [CCode (array_length = false)] int[] result_buf, out int result_len, int result_is_int, ArgBlock[] args); https://sources.debian.org/src/libdbi-drivers/0.9.0-13/drivers/pgsql/dbd_pgsql.h?hl=650#L650 #define PGSQL_CUSTOM_FUNCTIONS { \ ... "PQfn", \ All seem to be libpq wrappers. Then there is a handful of packages with a copy of libpq-fe.h that includes the function declaration. ... plus two other mentioning PQfn as "unimplemented". > 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. Keeping the symbol but making it return an error seems ok from the above I think. Christoph
