Обсуждение: BUG #8227: referential integrity problem

Поиск
Список
Период
Сортировка

BUG #8227: referential integrity problem

От
greg@antrez.pl
Дата:
The following bug has been logged on the website:

Bug reference:      8227
Logged by:          Greg Brzezinski
Email address:      greg@antrez.pl
PostgreSQL version: 9.2.4
Operating system:   linux
Description:        =


postgres=3D# CREATE TABLE test( id int primary key, name text );
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey"
for table "test"
CREATE TABLE
postgres=3D# CREATE TABLE test_item( id int primary key, test_id int
references test(id)  match full on update cascade on delete cascade, content
text );
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"test_item_pkey" for table "test_item"
CREATE TABLE
postgres=3D# CREATE OR REPLACE FUNCTION test_item_delete_lock() returns
trigger AS $f$
postgres$# begin
postgres$#     return null;
postgres$# end;
postgres$# $f$ language plpgsql;
CREATE FUNCTION
postgres=3D# CREATE TRIGGER test_item_delete_lock BEFORE DELETE ON test_item
FOR EACH ROW EXECUTE PROCEDURE test_item_delete_lock();
CREATE TRIGGER
postgres=3D#
postgres=3D# insert into test values (1, 'one');
INSERT 0 1
postgres=3D# insert into test_item values (1, 1, 'for one');
INSERT 0 1
postgres=3D# delete from test where id =3D 1;
DELETE 1
postgres=3D# select * from test_item;
 id | test_id | content
----+---------+---------
  1 |       1 | for one
(1 row)

postgres=3D# select * from test;
 id | name
----+------
(0 rows)


Is it ok that we loose referential integrity by locking DELETE on table
test_item ?

Re: BUG #8227: referential integrity problem

От
Tom Lane
Дата:
greg@antrez.pl writes:
> Is it ok that we loose referential integrity by locking DELETE on table
> test_item ?

Yes.  If you put a trigger on a table involved in an FK constraint, it's
your responsibility that the trigger doesn't break FK update operations.

            regards, tom lane