Re: Does 'instead of delete' trigger support modification of OLD

Hello Bruce,

Friday, November 8, 2019, 12:28:18 AM, you wrote:

> On Thu, Nov 7, 2019 at 04:26:55PM -0500, Bruce Momjian wrote:
>> On Thu, Nov 7, 2019 at 11:24:29AM +0200, Eugen Konkov wrote:
>> > >> As far as allowing DELETE to modify the trigger row for RETURNING, I am
>> > >> not sure how much work it would take to allow that, but it seems like it
>> > >> is a valid requite, and if so, I can add it to the TODO list.
>> >
>> > > Yes, Add please into TODO the feature to "allowing DELETE to modify the trigger row
>> > > for RETURNING". Becuase, as I have described at first letter, without
>> > > this the RETURNING rows **does not correspond actually deleted data**
>> >
>> > > Thank you.
>>
>> I have added a TODO item:
>>
>> Allow DELETE triggers to modify rows, for use by RETURNING

> Thinking some more on this, I now don't think a TODO makes sense, so I
> have removed it.

> Triggers are designed to check and modify input data, and since DELETE
> has no input data, it makes no sense. In the attached SQL script, you
> can see that only the BEFORE INSERT trigger fires, so there is no way
> even with INSERT to change what is passed after the write to RETURNING.
> What you can do is to modify the returning expression, which is what I
> have done for the last query --- hopefully that will help you.

You lost my idea. First of all I am talking about views and an
INSTEAD OF triggers.

INSERT/UPDATE operation present which data is added into DB
DELETE operation present which data is deleted from DB
(in my case I am not deleted exact that data which matched by where.
See example below)

Thus INSTEAD OF INSERT/UPDATE triggers are designed to check and modify input data
eg. we can insert/update something different then incoming data (here
we are modifying NEW)

Thus INSTEAD OF DELETE triggers are designed to check and delete **output** data
eg. we can delete something different then underlaid data (here we are
modifying OLD)

for example, we have next data: 1 2 3 4 5 6 7 8
it is not presented by eight rows, but instead it is presented as one
row with range data type: [1..8]

When we insert data we will not get new row, we change current:
insert into table values ( 9 ) will result
[1..9]
instead of
[1..8]
9

So lets look into INSTEAD OF DELETE trigger when we deleting
data:
delete from table where x in ( 5, 6, 7 );
after deleting this we should get:
[1..4]
[8..9]

thus
with t1 as ( delete from table where x in ( 5, 6, 7 ) returning * )
select * from t1
should return:
[5..7]
instead of
[1..9]
because we does not delete ALL [1..9], we just delete ONLY [5..7]

Thus I need to change matched row OLD.x from [1..9] to [5..7]

Please reread my first letter. There I describe more real life example
when I am manipulating bi-temporal data.

where some value exist at given period:
id | app_period | value
7 [2019-01-01, 2019-04-05) 207

And I am deleting third month: [ 2019-03-01, 2019-04-01 )
with t1 as ( delete from table where app_period && [ 2019-03-01,
2019-04-01 ) returning * )
select * from t1;
7 [ 2019-03-01, 2019-04-01 ) 207

select * from table;
7 [ 2019-01-01, 2019-03-01 ) 207
7 [ 2019-04-01, 2019-04-05 ) 207

--
Best regards,
Eugen Konkov