Re: CommandStatus from insert returning when using a portal.

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: CommandStatus from insert returning when using a portal.
Дата
Msg-id CADK3HH+6XcORTMLp=a+AnHkc6MoaEjXXau4XNK4mBMOKtQTLag@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CommandStatus from insert returning when using a portal.  (chap@anastigmatix.net)
Ответы Re: CommandStatus from insert returning when using a portal.  (chap@anastigmatix.net)
Список pgsql-hackers



On Fri, 14 Jul 2023 at 15:40, <chap@anastigmatix.net> wrote:
On 2023-07-14 14:19, David G. Johnston wrote:
> Because of the returning they all need a portal so far as the server is
> concerned and the server will obligingly send the contents of the
> portal
> back to the client.

Dave's pcap file, for the fetch count 0 case, does not show any
portal name used in the bind, describe, or execute messages, or
any portal close message issued by the client afterward. The server
may be using a portal in that case, but it seems more transparent
to the client when fetch count is zero.


There is no portal for fetch count 0. 
 
Perhaps an easy rule would be, if the driver itself adds RETURNING
because of a RETURN_GENERATED_KEYS option, it should also force the
fetch count to zero and collect all the returned rows before
executeUpdate returns, and then it will have the right count
to return?

Well that kind of negates the whole point of using a cursor in the case where you have a large result set.

The rows are subsequently fetched in rs.next()

Solves one problem, but creates another.

Dave

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Farias de Oliveira
Дата:
Сообщение: Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: CommandStatus from insert returning when using a portal.