On Thu, Nov 20, 2014 at 1:42 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
