On Thu, Nov 20, 2014 at 1:42 PM, Peter Geoghegan <pg@heroku.com> wrote:
> Would you be happy to just know that certain
> rows were either inserted or updated in the context of an UPSERT (and
> not cancelled by a BEFORE ROW INSERT or UPDATE trigger returning
> NULL)
Of course, having the WHERE clause in the auxiliary UPDATE not pass
would also be cause to *not* return/project the not-processed row/slot
(in a world where we do something with RETURNING in respect of rows
actually processed by the auxiliary UPDATE). I mean, you're seeing the
final version of the row when RETURNING with an UPDATE, and if the
UPDATE is never evaluated, then the would-be final version (which is
generally based on the TARGET tuple and EXLCUDED tuple, as processed
by the UPDATE) never exists, and so clearly cannot be projected by
RETURNING.
This explanation a tiny bit misleading, because the rows/slots not
affected by the UPDATE (or INSERT) are still *locked*, even when the
UPDATE's WHERE clause does not pass - they have been processed to the
extent that they were locked. This is also true of postgres_fdw in
certain situations, but it seems like a very minor issue.
--
Peter Geoghegan
