MIME-Version: 1.0
References: <ahXE28klgxIJXBLq@nathan>
In-Reply-To: <ahXE28klgxIJXBLq@nathan>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Tue, 26 May 2026 10:42:47 -0700
Message-ID: 
 <CAOYmi+m3bKWfHhAj3iKBa3mKj=_4MO3xY2WpBsB4Hx7yyAE7rw@mail.gmail.com>
Subject: Re: future of PQfn()
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2Bm3bKWfHhAj3iKBa3mKj%3D_4MO3xY2WpBsB4Hx7yyAE7rw%40mail.gmail.com>
Precedence: bulk

On Tue, May 26, 2026 at 9:05=E2=80=AFAM Nathan Bossart <nathandbossart@gmai=
l.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 stu=
b
> 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 i=
s
> 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 w=
e
> could take is to just send the query via PQexecParams(), but a simple tes=
t
> (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