On Tue, Jul 19, 2022 at 4:44 AM Morris de Oryx <morrisdeo...@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 of detail, and folks have been wanting to break down rows > submitted, rows inserted, and rows updated a bit better. Rows submitted is > easy and rows inserted is too...update is an estimate as I'm not using > anything fancy with xmax() to sort out what 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
