public inbox for [email protected]  

help / color / mirror / Atom feed

From: Christoph Berg <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: [email protected]
Subject: Re: future of PQfn()
Date: Tue, 26 May 2026 18:53:31 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <ahXE28klgxIJXBLq@nathan>
References: <ahXE28klgxIJXBLq@nathan>

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

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

;; "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

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: <[email protected]>

* 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