Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> 4. User charlie revokes alice's membership in admin. >>> >>> Now what? Alice's FK constraint is violated, according to the rules >>> KaiGai proposes. Shall REVOKE have to grovel through every table in the >>> database looking for possible violations ... and of course locking the >>> entire DB against writes while it does it? That's not gonna fly. I >>> also note that the failure would expose knowledge of the contents of BT >>> and AT to charlie, which might not be thought desirable either. > >> I assume Alice now gets an error on the query that references the >> now-invisible foreign key --- that sounds reasonable to me.
In my design, these errors are happen when PK is tries to update or delete (and kicked trigger functions for FK constraint). These violated tuples are simply filtered. > You mean her data just disappears? Doesn't sound very reasonable to me. In reference cases, we can consider she looks the tables via something like VIEWs implicitly. The "VIEW" can hide several tuple, but it does not break any reference consistency in the raw level. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <[EMAIL PROTECTED]> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
