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.
