On Wed, Jul 12, 2023 at 2:59 PM Dave Cramer <davecra...@gmail.com> wrote:
> On Wed, 12 Jul 2023 at 17:49, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Dave Cramer <davecra...@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.
