Re: CommandStatus from insert returning when using a portal.

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: CommandStatus from insert returning when using a portal.
Дата
Msg-id CAKFQuwY55Qhb+1LK3jUibGXHmyH4-AAjw6dGFJP7wZeW74iX1Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CommandStatus from insert returning when using a portal.  (Dave Cramer <davecramer@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
On Wed, Jul 12, 2023 at 2:59 PM Dave Cramer <davecramer@gmail.com> wrote:
On Wed, 12 Jul 2023 at 17:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dave Cramer <davecramer@gmail.com> writes:
> Obviously I am biased by the JDBC API which would like to have
> PreparedStatement.execute() return the number of rows inserted
> without having to wait to read all of the rows returned

Umm ... you do realize that we return the rows on-the-fly?
I do realize that. 
The server does not know how many rows got inserted/returned
Well I haven't looked at the code, but it seems unintuitive that adding the returning clause changes the semantics of insert. 


It doesn't have to - the insertions are always "as rows are produced", it is just that in the non-returning case the final row can be sent to /dev/null instead of the client (IOW, there is always some destination).  In both cases the total number of rows inserted are only reliably known when the top executor node requests a new tuple and its immediate predecessor says "no more rows present".

David J.

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

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: CommandStatus from insert returning when using a portal.
Следующее
От: David Rowley
Дата:
Сообщение: Re: document the need to analyze partitioned tables