public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jacob Champion <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: [email protected]
Subject: Re: future of PQfn()
Date: Tue, 26 May 2026 10:42:47 -0700
Message-ID: <CAOYmi+m3bKWfHhAj3iKBa3mKj=_4MO3xY2WpBsB4Hx7yyAE7rw@mail.gmail.com> (raw)
In-Reply-To: <ahXE28klgxIJXBLq@nathan>
References: <ahXE28klgxIJXBLq@nathan>

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

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: <CAOYmi+m3bKWfHhAj3iKBa3mKj=_4MO3xY2WpBsB4Hx7yyAE7rw@mail.gmail.com>

* 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