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.
No comments:
Post a Comment