Re: CommandStatus from insert returning when using a portal.

On Wed, Jul 12, 2023 at 2:59 PM Dave Cramer <davecramer(at)gmail(dot)com> wrote:

> On Wed, 12 Jul 2023 at 17:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Dave Cramer <davecramer(at)gmail(dot)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.