Re: CommandStatus from insert returning when using a portal. - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: CommandStatus from insert returning when using a portal.
Date
Msg-id CAKFQuwY8JV31dHuaMbpkgXRLcW3jBt+0pTqbXVsKguHcy+LmfA@mail.gmail.com
Whole thread Raw
In response to Re: CommandStatus from insert returning when using a portal.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jul 12, 2023 at 2:49 PM 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?
The server does not know how many rows got inserted/returned
until it's run the query to completion, at which point all
the data has already been sent to the client

Doesn't this code contradict that statement?

src/backend/tcop/pquery.c
/*
* If we have not yet run the command, do so, storing its
* results in the portal's tuplestore.  But we don't do that
* for the PORTAL_ONE_SELECT case.
*/
if (portal->strategy != PORTAL_ONE_SELECT && !portal->holdStore)
    FillPortalStore(portal, isTopLevel);
/*
* Now fetch desired portion of results.
*/
nprocessed = PortalRunSelect(portal, true, count, dest);


Not sure we'd want to lock ourselves into this implementation but at least as it stands now we could send a message with the portal size after calling FillPortalStore and prior to calling PortalRunSelect.

David J.

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Dumping policy on a table belonging to an extension is expected?
Next
From: Peter Smith
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication