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
