Thomas Munro <mu...@ip9.org> writes:
> On 3 October 2014 00:18, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> The spec clearly says one value per row, not one per statement; so
>> command ID is very definitely not the right thing.
> I think (command ID, estate->es_processed) would work.
Not terribly well, eg each new transaction starts over at command ID 1.
You could fix that particular objection by also tracking virtual xid.
But the bigger issue is that using es_processed for this seems like
an utter hack. It's not meant to be anything but statistical, and it's
not maintained anyway for non-canSetTag queries (ie, DO ALSO rule
commands). That reflects the fact that what it's meant to do is count the
number of rows returned to the executor's caller, which isn't necessarily
the definition we'd need here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
