Re: PATCH: Batch/pipelining support for libpq - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: PATCH: Batch/pipelining support for libpq
Date
Msg-id 20210210235147.GA32273@alvherre.pgsql
Whole thread Raw
In response to Re: PATCH: Batch/pipelining support for libpq  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: PATCH: Batch/pipelining support for libpq  (Craig Ringer <craig.ringer@enterprisedb.com>)
List pgsql-hackers
On 2021-Jan-21, Alvaro Herrera wrote:

> As you can see in an XXX comment in the libpq test program, the current
> implementation has the behavior that PQgetResult() returns NULL after a
> batch is finished and has reported PGRES_BATCH_END.  I don't know if
> there's a hard reason to do that, but I'd like to supress it because it
> seems weird and out of place.

Hello Craig, a question for you since this API is your devising.  I've
been looking at changing the way this works to prevent those NULL
returns from PQgetResult.  That is, instead of having what seems like a
"NULL separator" of query results, you'd just get the PGRES_BATCH_END to
signify a batch end (not a NULL result after the BATCH_END); and the
normal PGRES_COMMAND_OK or PGRES_TUPLES_OK etc when the result of a
command has been sent.  It's not working yet so I'm not sending an
updated patch, but I wanted to know if you had a rationale for including
this NULL return "separator" or was it just a convenience because of how
the code grew together.

Such a decision has obvious consequences for the test program (which
right now expects that PQgetResult() returns NULL at each step); and
naturally for libpq's internal state machine that controls how it all
works.

Thanks,

-- 
Álvaro Herrera                            39°49'30"S 73°17'W



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)
Next
From: Justin Pryzby
Date:
Subject: Re: doc review for v14