Thread: [Patch proposal] libpq portal support
Hello everybody,
--
Our company was in desperate need of portals in async interface of libpq, so we patched it.
We would be happy to upstream the changes.
The description of changes:
Two functions in libpq-fe.h:
PQsendPortalBindParams for sending a command to bind a portal to a previously prepared statement;
PQsendPortalExecute for executing a previously bound portal with a given number of rows.
A patch to pqParseInput3 in fe-protocol3.c to handle the `portal suspended` message tag.
The patch is ready for review, but it lacks documentation, tests and usage examples.
There are no functions for sending bind without params and no functions for sync interface, but they can easily be added to the feature.
Thank you,
Sergei Fedorov
On Thu, 17 Oct 2019 at 03:12, Sergei Fedorov <sergei.a.fedorov@gmail.com> wrote:
Hello everybody,Our company was in desperate need of portals in async interface of libpq, so we patched it.We would be happy to upstream the changes.The description of changes:Two functions in libpq-fe.h:PQsendPortalBindParams for sending a command to bind a portal to a previously prepared statement;PQsendPortalExecute for executing a previously bound portal with a given number of rows.A patch to pqParseInput3 in fe-protocol3.c to handle the `portal suspended` message tag.The patch is ready for review, but it lacks documentation, tests and usage examples.There are no functions for sending bind without params and no functions for sync interface, but they can easily be added to the feature.
If possible, please rebase it on top of git master.
Some explanation for why you have this need and what problems this solves for you would be helpful as well.
--
Hello everybody,
Yes, we will be happy to put our patch under the PostgreSQL License.
Patch is attached to this email, master was rebased to head prior to creating the patch.
We are using a C++ wrapper on top of libpq for using database connections in multithreaded asynchronous applications. For security reasons (and partially because we are too lazy to escape query parameters) we use prepared queries and parameter binding for execution. There are situations when we need to fetch the query results not in one batch but in a `paged` way, the most convenient way is to use the portals feature of PosgreSQL protocol.
пт, 18 окт. 2019 г. в 15:21, Craig Ringer <craig@2ndquadrant.com>:
On Thu, 17 Oct 2019 at 03:12, Sergei Fedorov <sergei.a.fedorov@gmail.com> wrote:Hello everybody,Our company was in desperate need of portals in async interface of libpq, so we patched it.We would be happy to upstream the changes.The description of changes:Two functions in libpq-fe.h:PQsendPortalBindParams for sending a command to bind a portal to a previously prepared statement;PQsendPortalExecute for executing a previously bound portal with a given number of rows.A patch to pqParseInput3 in fe-protocol3.c to handle the `portal suspended` message tag.The patch is ready for review, but it lacks documentation, tests and usage examples.There are no functions for sending bind without params and no functions for sync interface, but they can easily be added to the feature.If you are happy to put it under The PostgreSQL License, then sending it as an attachment here is the first step.If possible, please rebase it on top of git master.Some explanation for why you have this need and what problems this solves for you would be helpful as well.--
Thank you,
Sergei Fedorov
Attachment
On Thu, 7 Nov 2019 at 17:43, Sergei Fedorov <sergei.a.fedorov@gmail.com> wrote:
Hello everybody,Yes, we will be happy to put our patch under the PostgreSQL License.Patch is attached to this email, master was rebased to head prior to creating the patch.We are using a C++ wrapper on top of libpq for using database connections in multithreaded asynchronous applications. For security reasons (and partially because we are too lazy to escape query parameters) we use prepared queries and parameter binding for execution. There are situations when we need to fetch the query results not in one batch but in a `paged` way, the most convenient way is to use the portals feature of PosgreSQL protocol.
Thanks. That's a really good reason. It'd also bring libpq closer to feature-parity with PgJDBC.
Please add it to the commitfest app https://commitfest.postgresql.org/
On Thu, 7 Nov 2019 at 17:43, Sergei Fedorov <sergei.a.fedorov@gmail.com> wrote:
Hello everybody,Yes, we will be happy to put our patch under the PostgreSQL License.Patch is attached to this email, master was rebased to head prior to creating the patch.We are using a C++ wrapper on top of libpq for using database connections in multithreaded asynchronous applications. For security reasons (and partially because we are too lazy to escape query parameters) we use prepared queries and parameter binding for execution. There are situations when we need to fetch the query results not in one batch but in a `paged` way, the most convenient way is to use the portals feature of PosgreSQL protocol.
By way of initial patch review: there's a lot of copy/paste here that should be avoided if possible. It looks like the added function PQsendPortalBindParams() is heavily based on PQsendQueryGuts(), which is the common implementation shared by the existing PQsendQueryParams() and PQsendQueryPrepared() .
Similar for PQsendPortalExecute().
I'd like to see the common code factored out, perhaps by adding the needed functionality into PQsendQueryGuts() etc.
The patch is also missing documentation; please add it to doc/src/sgml/libpq.sgml in docbook XML format. See the existing function examples.
I'd ask you to add test cover, but we don't really have a useful test suite for libpq yet, so there's not much you can do there. It definitely won't fly without the docs and copy/paste reduction though.