Re: PATCH: Batch/pipelining support for libpq

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: PATCH: Batch/pipelining support for libpq
Дата
Msg-id 20210210235147.GA32273@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: PATCH: Batch/pipelining support for libpq  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: PATCH: Batch/pipelining support for libpq  (Craig Ringer <craig.ringer@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: doc review for v14