Thread

Re: future of PQfn()

Jacob Champion <jacob.champion@enterprisedb.com> — 2026-05-26T17:42:47Z

On Tue, May 26, 2026 at 9:05 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> 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.

That seems reasonable to me. (We may want to exercise the
PqMsg_FunctionCall message more explicitly in our test suite at the
same time we do that...)

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

I think we can probably wipe it out, personally.

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

Short-term, keeping it around seems fine.

Long-term, it doesn't feel great that the alternatives we tell other
people to use are... worse. Surely other clients of libpq run into the
layering violation problem with prepared statements, as well?

--Jacob