I was testing creating a rule that uses RETURNING and noticed a difference between the extended query protocol and the simple query protocol. In the former, RETURNING is ignored (at least in my case) and the latter it is respected:
CREATE table test (id bigint, deleted boolean);
CREATE RULE soft_delete AS ON DELETE TO test DO INSTEAD (UPDATE test set deleted = true WHERE id = old.id RETURNING old.*);
INSERT INTO test values (1, false);
# extended protocol result
postgres=# DELETE FROM test WHERE id = $1 RETURNING * \bind 1 \g
DELETE 0
# simple protocol result
postgres=# DELETE FROM test WHERE id = 1 RETURNING *;
id | deleted
----+---------
1 | t
(1 row)
DELETE 0
I was wondering if this is something that is just fundamentally not expected to work or if it might be able to work without jeopardizing critical parts of Postgres. If the latter I was interested in digging through the code and seeing if I could figure it out.
Note that I work on a driver/client for Postgres and the example above came from a user. I'm not sure if it's the best way to do what they want but their question sparked my interest in the general behaviour of returning from rules with the extended query protocol.
