>>>>> "Tom" == Tom Lane <t...@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 at Tom> command ID 1. You could fix that particular objection by also Tom> tracking virtual xid. But the bigger issue is that using Tom> es_processed for this seems like an utter hack. It's not meant Tom> to be anything but statistical, and it's not maintained anyway Tom> for non-canSetTag queries (ie, DO ALSO rule commands). That Tom> reflects the fact that what it's meant to do is count the number Tom> of rows returned to the executor's caller, which isn't Tom> 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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
