Re: NEXT VALUE FOR

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: NEXT VALUE FOR
Дата
Msg-id 87zjdb8gvn.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: NEXT VALUE FOR  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_receivexlog and replication slots
Следующее
От: Robert Haas
Дата:
Сообщение: Re: replicating DROP commands across servers