Re: NEXT VALUE FOR - Mailing list pgsql-hackers

From Tom Lane
Subject Re: NEXT VALUE FOR
Date
Msg-id 22006.1412460234@sss.pgh.pa.us
Whole thread Raw
In response to Re: NEXT VALUE FOR  (Thomas Munro <munro@ip9.org>)
Responses Re: NEXT VALUE FOR
List pgsql-hackers
Thomas Munro <munro@ip9.org> writes:
> On 3 October 2014 00:18, Tom Lane <tgl@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Aussie timezone database changes incoming
Next
From: Michael Paquier
Date:
Subject: Re: pg_receivexlog and replication slots