With a 'regular' DELETE operation you only get to know the number of affected rows. To get more info or actions you have to use a trigger or a foreign key. Anoter posibility is doing a SELECT and then a DELETE and with the correct transaction isolation a transactional support this will work.
With the support for the RETURNING keyword this has become easier to do and it will probably bennefit performance and save you a few roundtrips and a few lines of code.
There is already support for RETURNING in PostgreSQL. And PostgreSQL has an other nifty feature for which RETURNING really helps: CTE or common table expressions or the WITH keyword. I really hope to see CTE support in MySQL or MariaDB some day.
An example from RETURNING and CTE in PostgreSQL:
demo=# select * from t1; id | name ----+------- 1 | test1 2 | test2 3 | test3 4 | test1 5 | test2 6 | test3 (6 rows) demo=# WITH del_res AS (DELETE FROM t1 RETURNING id) demo-# SELECT CONCAT('Removed ID ',id) info FROM del_res; info -------------- Removed ID 1 Removed ID 2 Removed ID 3 Removed ID 4 Removed ID 5 Removed ID 6 (6 rows) demo=#
So my conclusion: Returning a resultset for DELETE is helpfull, and is one step in the direction of CTE support.
The next step step is to get the RETURNING keyword to work for UPDATE.