Re: Proposal: ON UPDATE REMOVE foreign key action - Mailing list pgsql-hackers

From Vitaly Burovoy
Subject Re: Proposal: ON UPDATE REMOVE foreign key action
Date
Msg-id CAKOSWNk6HvS4bzGDBt0rcYWTWhEV3_e2=QiZujrx+upcZ0uy4A@mail.gmail.com
Whole thread Raw
In response to Proposal: ON UPDATE REMOVE foreign key action  (Kirill Berezin <enelar@exsul.net>)
Responses Re: Proposal: ON UPDATE REMOVE foreign key action  (Kirill Berezin <enelar@exsul.net>)
List pgsql-hackers
On 10/3/16, Kirill Berezin <enelar@exsul.net> wrote:
> *One-line Summary:* On foreign key update we unable to remove all depended
> records. Currently we have "ON REMOVE CASCADE DELETE", but no "ON UPDATE
> CASCADE DELETE". We can only update field to NULL or DEFAULT.

I think there are three causes why we don't have it implemented.
The first one is that there is no such grammar in the SQL spec (your
version is also wrong: SQL spec has "ON DELETE CASCADE" as well as "ON
DELETE CASCADE" [or any other action instead of "CASCADE"]).

The second one is in almost all cases there is no reason to delete
rows because of updating referenced row. If these rows are still
connected, they should be updated, if not --- left as is ("NO ACTION")
or with reference link deleted ("SET NULL" or "DEFAULT").
These rows has data, that's why they are still in tables. They can be
deleted (by reference) if and only if "parent" or "linked" data (all
data, not just referenced key) is deleted.

> *Business Use-case:* Cache expiration on hash/version update. Revoke all
> access on account id update.

> In my case i met this situation: I am using access links to share user
> account. Account owner can give private link to somebody, and its session
> become mirrored. (Owner access to account granted).

And the third cause is avoiding of bad design. If you has to give
access to anyone and you know access will be revoked soon (or late),
it is wise to give private link with different identificator which can
be easily found and removed by a grantor id (your id).

> You cant imagine facebook desktop and mobile sessions.

Which, of course, have different session ids. You can revoke session
without renaming your own.

> It's just shortcut for
> entering credentials. Now i am implementing "revoke all but me". Its done
> simple, since each user is uuid indexed, i am just generate new uuid for
> current account. Old uuid become invalid to other sessions - since no
> record is found in base.
> I want to remove any pending access links, prevent bad guy restore access.
> I can possibly set linked account to NULL,

Why just don't delete them when grantor revokes access?

> and then clear record on
> expiration, but i feel that automatically removing on update event is more
> rational.

I personally don't see necessity to introduce new non-spec grammar.
If you think I has not understood you, send an example with schema ---
what you have now and how you expect it should be.

-- 
Best regards,
Vitaly Burovoy



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Rename max_parallel_degree?
Next
From: Tom Lane
Date:
Subject: Re: contrib/pg_visibility craps out in assert-enabled builds