Re: NEXT VALUE FOR <sequence>

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <munro(at)ip9(dot)org>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: NEXT VALUE FOR <sequence>
Date: 2014-10-04 22:03:54
Message-ID: 22006.1412460234@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <munro(at)ip9(dot)org> writes:
> On 3 October 2014 00:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-10-04 23:03:06 Re: pg_receivexlog and replication slots
Previous Message Tom Lane 2014-10-04 21:55:32 Re: Aussie timezone database changes incoming