Re: [HACKERS] Allow INSTEAD OF DELETE triggers to modify the tuple for RETURNING
| От | Rahila Syed |
|---|---|
| Тема | Re: [HACKERS] Allow INSTEAD OF DELETE triggers to modify the tuple for RETURNING |
| Дата | |
| Msg-id | CAH2L28vbODgMnn-j0coRbtgMGWKiwFtuxXh2EEPNzALJC5L7GA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Allow INSTEAD OF DELETE triggers to modify the tuple for RETURNING (Aleksander Alekseev <aleksander@timescale.com>) |
| Список | pgsql-hackers |
Hi,
> So I'm suggesting to change this behavior and allow INSTEAD OF DELETE
> triggers to modify the OLD tuple and use that for RETURNING instead of> returning the tuple in planSlot. Attached is a WIP patch implementing that.
>
I am trying to understand the basic idea behind the change. What is the
use-case for allowing the OLD tuple to be modified in the INSTEAD of DELETE
triggers.
AFAIU no matter what we return from the trigger OLD/NEW or NULL, the delete
operation is skipped, so what is the point of modifying the OLD row in your test
for example.
If the requirement is to show the recent row in the returning clause, is fetching the
row from heap and copying into the returning slot not enough?
operation is skipped, so what is the point of modifying the OLD row in your test
for example.
If the requirement is to show the recent row in the returning clause, is fetching the
row from heap and copying into the returning slot not enough?
In the tests shown as follows, inspite of the output showing 'DELETE 1',
no row is actually deleted from the table or the view. Probably this
is an existing behavior but I think this is misleading.
```
DELETE FROM test_ins_del_view where a = 1 returning a;
NOTICE: old.a 4
a
---
4
(1 row)
DELETE 1
```
FWIW, it might be good to include in tests the example
to demonstrate the problem regarding the concurrent transactions,
one of which is modifying the row and the other returning it
after attempting DELETE.
Thank you,
Rahila Syed
On Fri, Mar 15, 2024 at 7:57 PM Aleksander Alekseev <aleksander@timescale.com> wrote:
Hi,
> it took me a while to figure out why the doc build fails.
>
> [...]
>
> Anyway, based on your patch, I modified it, also added a slightly more complicated test.
Thank you for keeping the patch up-to-date. Unfortunately, it seems to
be needing another rebase, according to cfbot.
Best regards,
Aleksander Alekseev (wearing co-CFM hat)
В списке pgsql-hackers по дате отправления: