diff options
| author | Jan Wieck | 2003-04-07 20:30:38 +0000 |
|---|---|---|
| committer | Jan Wieck | 2003-04-07 20:30:38 +0000 |
| commit | cd203f33958b99656e8486351be08197a9a73d76 (patch) | |
| tree | 1b9ea0bc4c2b5b6910f051a9b41964e2d69c4f14 /src/test | |
| parent | afe1185cf082c4c1bb5cafcffa544e0f5d4fc97f (diff) | |
Avoid primary key lookup (and lock) if foreign key does not change
on UPDATE.
This get's rid of the long standing annoyance that updating a row
that has foreign keys locks all the referenced rows even if the
foreign key values do not change.
The trick is to actually do a check identical to NO ACTION after an
eventually done UPDATE in the SET DEFAULT case. Since a SET DEFAULT
operation should have moved referencing rows to a new "home", a following
NO ACTION check can only fail if the column defaults of the referencing
table resulted in the key we actually deleted. Thanks to Stephan.
Jan
Diffstat (limited to 'src/test')
| -rw-r--r-- | src/test/regress/expected/foreign_key.out | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/test/regress/expected/foreign_key.out b/src/test/regress/expected/foreign_key.out index 7a0c47a9685..580762f93bd 100644 --- a/src/test/regress/expected/foreign_key.out +++ b/src/test/regress/expected/foreign_key.out @@ -882,7 +882,7 @@ delete from pktable where base1=2; ERROR: $1 referential integrity violation - key (base1,ptest1)=(2,2) in pktable still referenced from pktable -- fails (1,1) is being referenced (twice) update pktable set base1=3 where base1=1; -ERROR: $1 referential integrity violation - key (base2,ptest2)=(1,1) referenced from pktable not found in pktable +ERROR: $1 referential integrity violation - key (base1,ptest1)=(1,1) in pktable still referenced from pktable -- this sequence of two deletes will work, since after the first there will be no (2,*) references delete from pktable where base2=2; delete from pktable where base1=2; |