On Tue, May 26, 2026 at 9:05 AM Nathan Bossart <[email protected]> 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
