On Tue, Jul 19, 2022 at 4:44 AM Morris de Oryx <morrisdeoryx@gmail.com> wrote:
> My reason for xmax() in the result is to break down the affected rows count into an insert count, and a modified
estimate.Not super critical, but helpful. I've built out some simple custom logging table in out system for this kind
ofdetail, and folks have been wanting to break down rows submitted, rows inserted, and rows updated a bit better. Rows
submittedis easy and rows inserted is too...update is an estimate as I'm not using anything fancy with xmax() to sort
outwhat exactly happened.
I wonder whether you could just have the CTEs bubble up 1 or 0 and
then sum them at some stage, instead of relying on xmax. Presumably
your UPSERT simulation knows which thing it did in each case.
For MERGE itself, I wonder if some information about this should be
included in the command tag. It looks like MERGE already includes some
sort of row count in the command tag, but I guess perhaps it doesn't
distinguish between inserts and updates. I don't know why we couldn't
expose multiple values this way, though.
--
Robert Haas
EDB: http://www.enterprisedb.com
