Re: CommandStatus from insert returning when using a portal.
От | chap@anastigmatix.net |
---|---|
Тема | Re: CommandStatus from insert returning when using a portal. |
Дата | |
Msg-id | 918edda7e6a34c4a8f9d7b91b8d67703@anastigmatix.net обсуждение исходный текст |
Ответ на | Re: CommandStatus from insert returning when using a portal. ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: CommandStatus from insert returning when using a portal.
|
Список | pgsql-hackers |
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. 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? It seems that any approach leaving any of the rows unfetched at the time executeUpdate returns might violate a caller's expectation that the whole outcome is known by that point. Regards, -Chap
В списке pgsql-hackers по дате отправления: