On Tue, Jul 04, 2023 at 04:09:43PM +0900, Michael Paquier wrote:
> On Tue, Jul 04, 2023 at 08:28:40AM +0900, Michael Paquier wrote:
>> Sure, feel free. I was planning to look at and play more with it.
>
> Well, done.
For the sake of completeness, as I forgot to send my notes.
+ if (PQsendClose
On Tue, Jul 04, 2023 at 08:28:40AM +0900, Michael Paquier wrote:
> Sure, feel free. I was planning to look at and play more with it.
Well, done.
--
Michael
signature.asc
Description: PGP signature
On Mon, Jul 03, 2023 at 02:33:55PM +0200, Jelte Fennema wrote:
> @Michael is anything else needed from my side? If not, I'll mark the
> commitfest entry as "Ready For Committer".
Sure, feel free. I was planning to look at and play more with it.
--
Michael
signature.asc
Description: PGP signatur
@Michael is anything else needed from my side? If not, I'll mark the
commitfest entry as "Ready For Committer".
On Fri, Jun 23, 2023 at 09:39:00AM +0200, Jelte Fennema wrote:
> To be clear, it didn't actually change the behaviour. I only changed
> the error message, since it said the exact opposite of what it was
> expecting. I split this minor fix into its own commit now to clarify
> that. I think it would
On Fri, 23 Jun 2023 at 05:59, Michael Paquier wrote:
> [...]
> res = PQgetResult(conn);
> if (res == NULL)
> - pg_fatal("expected NULL result");
> + pg_fatal("expected non-NULL result");
>
> This should check for the NULL-ness of the result returned for
> PQclosePrepared() rath
On Tue, Jun 20, 2023 at 01:42:13PM +0200, Jelte Fennema wrote:
Thanks for updating the patch.
> On Tue, 20 Jun 2023 at 06:18, Michael Paquier wrote:
>> The amount of duplication between the describe and close paths
>> concerns me a bit. Should PQsendClose() and PQsendDescribe() be
>> merged int
On Tue, 20 Jun 2023 at 06:18, Michael Paquier wrote:
> The amount of duplication between the describe and close paths
> concerns me a bit. Should PQsendClose() and PQsendDescribe() be
> merged into a single routine (say PQsendCommand), that uses a message
> type for pqPutMsgStart and a queryclass
On Mon, Jun 19, 2023 at 02:49:44PM +0200, Jelte Fennema wrote:
> On Mon, 19 Jun 2023 at 14:17, jian he wrote:
>> I am not sure the following two following function comments are right
>
> They were incorrect indeed. Attached is a patch with those two updated.
The amount of duplication between
On Mon, 19 Jun 2023 at 14:17, jian he wrote:
> I am not sure the following two following function comments are right
They were incorrect indeed. Attached is a patch with those two updated.
On Mon, 19 Jun 2023 at 14:17, jian he wrote:
>
> On Mon, Jun 19, 2023 at 5:50 PM Jelte Fennema wrote:
On Mon, Jun 19, 2023 at 5:50 PM Jelte Fennema wrote:
>
> On Mon, 19 Jun 2023 at 11:44, Jelte Fennema wrote:
> > Done
>
> Now with the actual attachment.
>
> PS. Another connection pooler (PgCat) now also supports prepared
> statements, but only using Close not DEALLOCATE:
> https://postgresml.org
On Mon, 19 Jun 2023 at 11:44, Jelte Fennema wrote:
> Done
Now with the actual attachment.
PS. Another connection pooler (PgCat) now also supports prepared
statements, but only using Close not DEALLOCATE:
https://postgresml.org/blog/making-postgres-30-percent-faster-in-production
From 534c5c837ed
On Mon, 19 Jun 2023 at 04:52, jian he wrote:
> > /* Now that it's closed we should get an error when describing */
> > res = PQdescribePortal(conn, "cursor_one");
> > if (PQresultStatus(res) != PGRES_FATAL_ERROR)
> > pg_fatal("expected COMMAND_OK, got %s", PQresStatus(PQresultStatus(res)));
> shou
On Mon, 19 Jun 2023 at 01:57, Michael Paquier wrote:
> +static int
> +PQsendClose(PGconn *conn, char close_type, const char *close_target)
>
> Could it be better for this code path to issue an error if using a
> non-supported close_type rather than sending it? Okay, you are
> consistent with desc
now it works.
/src/test/modules/libpq_pipeline/libpq_pipeline.c
>
> /* Now that it's closed we should get an error when describing */
> res = PQdescribePortal(conn, "cursor_one");
> if (PQresultStatus(res) != PGRES_FATAL_ERROR)
> pg_fatal("expected COMMAND_OK, got %s", PQresStatus(PQresultStatus(r
On Sun, Jun 18, 2023 at 01:03:57PM +0200, Jelte Fennema wrote:
> Sorry about that. I attached a new patch that allows linking to the
> new functions (I forgot to add the functions to exports.txt). This new
> patch also adds some basic tests for these new functions.
I am okay with the arguments abo
On Sun, Jun 18, 2023 at 09:23:22PM +0800, jian he wrote:
> previously I cannot link it. with
> v2-0001-Support-sending-Close-messages-from-libpq.patch. now I can
> compile it, link it, but then run time error.
> same c program in the first email.
> when I run it ./a.out, then error:
> ./a.out: symb
On Sun, Jun 18, 2023 at 7:04 PM Jelte Fennema wrote:
>
> On Sat, 17 Jun 2023 at 15:34, jian he wrote:
> > I failed to link it. I don't know why.
>
> Sorry about that. I attached a new patch that allows linking to the
> new functions (I forgot to add the functions to exports.txt). This new
> patch
On Sat, 17 Jun 2023 at 15:34, jian he wrote:
> I failed to link it. I don't know why.
Sorry about that. I attached a new patch that allows linking to the
new functions (I forgot to add the functions to exports.txt). This new
patch also adds some basic tests for these new functions.
v2-0001-Supp
On Fri, Jun 16, 2023 at 11:28 PM Jelte Fennema wrote:
>
> On Fri, 16 Jun 2023 at 16:26, Craig Ringer wrote:
> > Nobody's implemented it.
> >
> > A patch to add PQclosePrepared and PQsendClosePrepared would be welcome. At
> > least, I think so...
>
> This might have been a pretty old thread. But
On Fri, 16 Jun 2023 at 16:26, Craig Ringer wrote:
> Nobody's implemented it.
>
> A patch to add PQclosePrepared and PQsendClosePrepared would be welcome. At
> least, I think so...
This might have been a pretty old thread. But I just took it upon me
to implement these functions (or well I mostly
21 matches
Mail list logo
