Re: NEXT VALUE FOR - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: NEXT VALUE FOR
Date
Msg-id 87zjdb8gvn.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: NEXT VALUE FOR  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> 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.
Tom> Not terribly well, eg each new transaction starts over atTom> command ID 1.  You could fix that particular
objectionby alsoTom> tracking virtual xid.  But the bigger issue is that usingTom> es_processed for this seems like an
utterhack.  It's not meantTom> to be anything but statistical, and it's not maintained anywayTom> for non-canSetTag
queries(ie, DO ALSO rule commands).  ThatTom> reflects the fact that what it's meant to do is count the numberTom> of
rowsreturned to the executor's caller, which isn'tTom> necessarily the definition we'd need here.
 

Maybe it would make sense to do something with a SubPlan, rather than
trying to hide everything inside a function?

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_receivexlog and replication slots
Next
From: Robert Haas
Date:
Subject: Re: replicating DROP commands across servers