rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/doc/TODO.detail/foreign

543 lines
22 KiB
Plaintext
Raw Blame History

From fjoe@iclub.nsu.ru Tue Jan 23 03:38:45 2001
Received: from mx.nsu.ru (root@mx.nsu.ru [193.124.215.71])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id DAA14458
for <pgman@candle.pha.pa.us>; Tue, 23 Jan 2001 03:38:24 -0500 (EST)
Received: from iclub.nsu.ru (root@iclub.nsu.ru [193.124.222.66])
by mx.nsu.ru (8.9.1/8.9.0) with ESMTP id OAA29153;
Tue, 23 Jan 2001 14:31:27 +0600 (NOVT)
Received: from localhost (fjoe@localhost)
by iclub.nsu.ru (8.11.1/8.11.1) with ESMTP id f0N8VOr15273;
Tue, 23 Jan 2001 14:31:25 +0600 (NS)
(envelope-from fjoe@iclub.nsu.ru)
Date: Tue, 23 Jan 2001 14:31:24 +0600 (NS)
From: Max Khon <fjoe@iclub.nsu.ru>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Bug in FOREIGN KEY
In-Reply-To: <200101230416.XAA04293@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0101231429310.12474-100000@iclub.nsu.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
hi, there!
On Mon, 22 Jan 2001, Bruce Momjian wrote:
>
> > This problem with foreign keys has been reported to me, and I have confirmed
> > the bug exists in current sources. The DELETE should succeed:
> >
> > ---------------------------------------------------------------------------
> >
> > CREATE TABLE primarytest2 (
> > col1 INTEGER,
> > col2 INTEGER,
> > PRIMARY KEY(col1, col2)
> > );
> >
> > CREATE TABLE foreigntest2 (col3 INTEGER,
> > col4 INTEGER,
> > FOREIGN KEY (col3, col4) REFERENCES primarytest2
> > );
> > test=> BEGIN;
> > BEGIN
> > test=> INSERT INTO primarytest2 VALUES (5,5);
> > INSERT 27618 1
> > test=> DELETE FROM primarytest2 WHERE col1 = 5 AND col2 = 5;
> > ERROR: triggered data change violation on relation "primarytest2"
I have another (slightly different) example:
--- cut here ---
test=> CREATE TABLE pr(obj_id int PRIMARY KEY);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'pr_pkey' for
table 'pr'
CREATE
test=> CREATE TABLE fr(obj_id int REFERENCES pr ON DELETE CASCADE);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
test=> BEGIN;
BEGIN
test=> INSERT INTO pr (obj_id) VALUES (1);
INSERT 200539 1
test=> INSERT INTO fr (obj_id) SELECT obj_id FROM pr;
INSERT 200540 1
test=> DELETE FROM fr;
ERROR: triggered data change violation on relation "fr"
test=>
--- cut here ---
we are running postgresql 7.1 beta3
/fjoe
From sszabo@megazone23.bigpanda.com Tue Jan 23 13:41:55 2001
Received: from megazone23.bigpanda.com (rfx-64-6-210-138.users.reflexcom.com [64.6.210.138])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id NAA19924
for <pgman@candle.pha.pa.us>; Tue, 23 Jan 2001 13:41:54 -0500 (EST)
Received: from localhost (sszabo@localhost)
by megazone23.bigpanda.com (8.11.1/8.11.1) with ESMTP id f0NIfLa41018;
Tue, 23 Jan 2001 10:41:21 -0800 (PST)
Date: Tue, 23 Jan 2001 10:41:21 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Jan Wieck <janwieck@Yahoo.com>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Bug in FOREIGN KEY
In-Reply-To: <200101230417.XAA04332@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.21.0101231031290.40955-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
> > Think I misinterpreted the SQL3 specs WR to this detail. The
> > checks must be made per statement, not at the transaction
> > level. I'll try to fix it, but we need to define what will
> > happen with referential actions in the case of conflicting
> > actions on the same key - there are some possible conflicts:
> >
> > 1. DEFERRED ON DELETE NO ACTION or RESTRICT
> >
> > Do the referencing rows reference to the new PK row with
> > the same key now, or is this still a constraint
> > violation? I would say it's not, because the constraint
> > condition is satisfied at the end of the transaction. How
> > do other databases behave?
> >
> > 2. DEFERRED ON DELETE CASCADE, SET NULL or SET DEFAULT
> >
> > Again I'd say that the action should be suppressed
> > because a matching PK row is present at transaction end -
> > it's not the same old row, but the constraint itself is
> > still satisfied.
I'm not actually sure on the cascade, set null and set default. The
way they are written seems to imply to me that it's based on the state
of the database before/after the command in question as opposed to the
deferred state of the database because of the stuff about updating the
state of partially matching rows immediately after the delete/update of
the row which wouldn't really make sense when deferred. Does anyone know
what other systems do with a case something like this all in a
transaction:
create table a (a int primary key);
create table b (b int references a match full on update cascade
on delete cascade deferrable initially deferred);
insert into a values (1);
insert into a values (2);
insert into b values (1);
delete from a where a=1;
select * from b;
commit;
From pgsql-hackers-owner+M3901@postgresql.org Fri Jan 26 17:00:24 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA10576
for <pgman@candle.pha.pa.us>; Fri, 26 Jan 2001 17:00:24 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f0QLtVq53019;
Fri, 26 Jan 2001 16:55:31 -0500 (EST)
(envelope-from pgsql-hackers-owner+M3901@postgresql.org)
Received: from smtp1b.mail.yahoo.com (smtp3.mail.yahoo.com [128.11.68.135])
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f0QLqmq52691
for <pgsql-hackers@postgresql.org>; Fri, 26 Jan 2001 16:52:48 -0500 (EST)
(envelope-from janwieck@yahoo.com)
Received: from j13.us.greatbridge.com (HELO jupiter.greatbridge.com) (216.54.52.153)
by smtp.mail.vip.suc.yahoo.com with SMTP; 26 Jan 2001 22:49:57 -0000
X-Apparently-From: <janwieck@yahoo.com>
Received: (from janwieck@localhost)
by jupiter.greatbridge.com (8.9.3/8.9.3) id RAA04701;
Fri, 26 Jan 2001 17:02:32 -0500
From: Jan Wieck <janwieck@Yahoo.com>
Message-Id: <200101262202.RAA04701@jupiter.greatbridge.com>
Subject: Re: [HACKERS] Bug in FOREIGN KEY
In-Reply-To: <200101262110.QAA06902@candle.pha.pa.us> from Bruce Momjian at "Jan
26, 2001 04:10:22 pm"
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Fri, 26 Jan 2001 17:02:32 -0500 (EST)
CC: Jan Wieck <janwieck@Yahoo.com>, Peter Eisentraut <peter_e@gmx.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: RO
Bruce Momjian wrote:
> Here is another bug:
>
> test=> begin;
> BEGIN
> test=> INSERT INTO primarytest2 VALUES (5,5);
> INSERT 18757 1
> test=> UPDATE primarytest2 SET col2=1 WHERE col1 = 5 AND col2 = 5;
> ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,10) not
> found
Schema?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From pgsql-hackers-owner+M3864@postgresql.org Fri Jan 26 10:07:36 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA17732
for <pgman@candle.pha.pa.us>; Fri, 26 Jan 2001 10:07:35 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f0QF3lq12782;
Fri, 26 Jan 2001 10:03:47 -0500 (EST)
(envelope-from pgsql-hackers-owner+M3864@postgresql.org)
Received: from mailout00.sul.t-online.com (mailout00.sul.t-online.com [194.25.134.16])
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f0QF0Yq12614
for <pgsql-hackers@postgresql.org>; Fri, 26 Jan 2001 10:00:34 -0500 (EST)
(envelope-from peter_e@gmx.net)
Received: from fwd01.sul.t-online.com
by mailout00.sul.t-online.com with smtp
id 14MALp-0006Im-00; Fri, 26 Jan 2001 15:59:45 +0100
Received: from peter.localdomain (520083510237-0001@[212.185.245.73]) by fmrl01.sul.t-online.com
with esmtp id 14MALQ-1Z0gkaC; Fri, 26 Jan 2001 15:59:20 +0100
Date: Fri, 26 Jan 2001 16:07:27 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Open 7.1 items
In-Reply-To: <3A70FA87.933B3D51@tpf.co.jp>
Message-ID: <Pine.LNX.4.30.0101261604030.769-100000@peter.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sender: 520083510237-0001@t-dialin.net
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: RO
Hiroshi Inoue writes:
> What does this item mean ?
> Is it the following ?
>
> begin;
> insert into pk (id) values (1);
> update(delete from) pk where id=1;
> ERROR: triggered data change violation on relation pk"
>
> If so, isn't it a simple bug ?
Depends on the definition of "bug". It's not spec compliant and it's not
documented and it's annoying. But it's been like this for a year and the
issue is well known and can normally be avoided. It looks like a
documentation to-do to me.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
From pgsql-hackers-owner+M3876@postgresql.org Fri Jan 26 13:07:10 2001
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id NAA26086
for <pgman@candle.pha.pa.us>; Fri, 26 Jan 2001 13:07:09 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f0QI4Vq30248;
Fri, 26 Jan 2001 13:04:31 -0500 (EST)
(envelope-from pgsql-hackers-owner+M3876@postgresql.org)
Received: from sectorbase2.sectorbase.com ([208.48.122.131])
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id f0QI3Aq30098
for <pgsql-hackers@postgreSQL.org>; Fri, 26 Jan 2001 13:03:11 -0500 (EST)
(envelope-from vmikheev@SECTORBASE.COM)
Received: by sectorbase2.sectorbase.com with Internet Mail Service (5.5.2653.19)
id <D49FAF71>; Fri, 26 Jan 2001 09:41:23 -0800
Message-ID: <8F4C99C66D04D4118F580090272A7A234D32C1@sectorbase1.sectorbase.com>
From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
To: "'Jan Wieck'" <janwieck@Yahoo.com>,
PostgreSQL HACKERS
<pgsql-hackers@postgresql.org>,
Bruce Momjian <root@candle.pha.pa.us>
Subject: RE: [HACKERS] Open 7.1 items
Date: Fri, 26 Jan 2001 10:02:59 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: RO
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> A well known issue, and I've asked multiple times how exactly
> we want to define the behaviour for deferred constraints. Do
> foreign keys reference just to a key value and are happy with
> it's existance, or do they refer to a particular row?
I think first. The last is closer to OODBMS world, not to [O]RDBMS one.
> Consider you have a deferred "ON DELETE CASCADE" constraint
> and do a DELETE, INSERT of a PK. Do the FK rows need to be
> deleted or not?
Good example. I think FK should not be deleted. If someone really
want to delete "old" FK then he can do
DELETE PK;
SET CONSTRAINT ... IMMEDIATE; -- FK need to be deleted here
INSERT PK;
> Consider you have a deferred "ON DELETE RESTRICT" and "ON
> UPDATE CASCADE" constraint. If you DELETE PK1 and UPDATE PK2
> to PK1, the FK2 rows need to follow, but does PK2 inherit all
> FK1 rows now so it's the master of both groups?
Yes. Again one can use SET CONSTRAINT to achieve desirable results.
It seems that SET CONSTRAINT was designed for these purposes - ie
for better flexibility.
Though, it would be better to look how other DBes handle all these
cases -:)
Vadim
From janwieck@yahoo.com Fri Jan 26 12:20:27 2001
Received: from smtp6.mail.yahoo.com (smtp6.mail.yahoo.com [128.11.69.103])
by candle.pha.pa.us (8.9.0/8.9.0) with SMTP id MAA22158
for <root@candle.pha.pa.us>; Fri, 26 Jan 2001 12:20:27 -0500 (EST)
Received: from j13.us.greatbridge.com (HELO jupiter.greatbridge.com) (216.54.52.153)
by smtp.mail.vip.suc.yahoo.com with SMTP; 26 Jan 2001 17:20:26 -0000
X-Apparently-From: <janwieck@yahoo.com>
Received: (from janwieck@localhost)
by jupiter.greatbridge.com (8.9.3/8.9.3) id MAA03196;
Fri, 26 Jan 2001 12:30:05 -0500
From: Jan Wieck <janwieck@yahoo.com>
Message-Id: <200101261730.MAA03196@jupiter.greatbridge.com>
Subject: Re: [HACKERS] Open 7.1 items
To: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>,
Bruce Momjian <root@candle.pha.pa.us>
Date: Fri, 26 Jan 2001 12:30:05 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: RO
Bruce Momjian wrote:
> Here are my open 7.1 items. Thanks for shrinking the list so far.
>
> ---------------------------------------------------------------------------
>
> FreeBSD locale bug
> Reorder INSERT firing in rules
I don't recall why this is wanted. AFAIK there's no reason
NOT to do so, except for the actual state of beeing far too
close to a release candidate.
> Philip Warner UPDATE crash
> JDBC LargeObject short read return value missing
> SELECT cash_out(1) crashes all backends
> LAZY VACUUM
> FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
A well known issue, and I've asked multiple times how exactly
we want to define the behaviour for deferred constraints. Do
foreign keys reference just to a key value and are happy with
it's existance, or do they refer to a particular row?
Consider you have a deferred "ON DELETE CASCADE" constraint
and do a DELETE, INSERT of a PK. Do the FK rows need to be
deleted or not?
Consider you have a deferred "ON DELETE RESTRICT" and "ON
UPDATE CASCADE" constraint. If you DELETE PK1 and UPDATE PK2
to PK1, the FK2 rows need to follow, but does PK2 inherit all
FK1 rows now so it's the master of both groups?
These are only two possible combinations. There are many to
think of. As said, I've asked before, but noone voted yet.
Move the item to 7.2 anyway, because changing this behaviour
would require massive changes in the trigger queue *and* the
generic RI triggers, which cannot be tested enough any more.
Jan
> Usernames limited in length
> Does pg_dump preserve COMMENTs?
> Failure of nested cursors in JDBC
> JDBC setMaxRows() is global variable affecting other objects
> Does JDBC Makefile need current dir?
> Fix for pg_dump of bad system tables
> Steve Howe failure query with rules
> ODBC/JDBC not disconnecting properly?
> Magnus Hagander ODBC issues?
> Merge MySQL/PgSQL translation scripts
> Fix ipcclean on Linux
> Merge global and template BKI files?
>
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From pgsql-general-owner+M590@postgresql.org Tue Nov 14 16:30:40 2000
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA22313
for <pgman@candle.pha.pa.us>; Tue, 14 Nov 2000 17:30:39 -0500 (EST)
Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28])
by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eAEMSJs66979;
Tue, 14 Nov 2000 17:28:21 -0500 (EST)
(envelope-from pgsql-general-owner+M590@postgresql.org)
Received: from megazone23.bigpanda.com (138.210.6.64.reflexcom.com [64.6.210.138])
by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eAEMREs66800
for <pgsql-general@postgresql.org>; Tue, 14 Nov 2000 17:27:14 -0500 (EST)
(envelope-from sszabo@megazone23.bigpanda.com)
Received: from localhost (sszabo@localhost)
by megazone23.bigpanda.com (8.11.1/8.11.0) with ESMTP id eAEMPpH69059;
Tue, 14 Nov 2000 14:25:51 -0800 (PST)
Date: Tue, 14 Nov 2000 14:25:51 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: "Beth K. Gatewood" <bethg@mbt.washington.edu>
cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] a request for some experienced input.....
In-Reply-To: <3A11ACA1.E5D847DD@mbt.washington.edu>
Message-ID: <Pine.BSF.4.21.0011141403380.68986-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org
Status: OR
On Tue, 14 Nov 2000, Beth K. Gatewood wrote:
> >
>
> Stephan-
>
> Thank you so much for taking the effort to answer this these questions. You
> help is truly appreciated....
>
> I just have a few points for clarification.
>
> >
> > MATCH PARTIAL is a specific match type which describes which rows are
> > considered matching rows for purposes of meeting or failing the
> > constraint. (In match partial, a fktable (NULL, 2) would match a pk
> > table (1,2) as well as a pk table (2,2). It's different from match
> > full in which case (NULL,2) would be invalid or match unspecified
> > in which case it would match due to the existance of the NULL in any
> > case). There are some bizarre implementation details involved with
> > it and it's different from the others in ways that make it difficult.
> > It's in my list of things to do, but I haven't come up with an acceptable
> > mechanism in my head yet.
>
> Does this mean, currently that I can not have foreign keys with null values?
Not exactly...
Match full = In FK row, all columns must be NULL or the value of each
column must not be null and there is a row in the PK table where
each referencing column equals the corresponding referenced
column.
Unspecified = In FK row, at least one column must be NULL or each
referencing column shall be equal to the corresponding referenced
column in some row of the referenced table
Match partial is similar to match full except we ignore the null columns
for purposes of the each referencing column equals bit.
For example:
PK Table Key values: (1,2), (1,3), (3,3)
Attempted FK Table Key values: (1,2), (1,NULL), (5,NULL), (NULL, NULL)
(hopefully I get this right)...
In match full, only the 1st and 4th fk values are valid.
In match partial, the 1st, 2nd, and 4th fk values are valid.
In match unspecified, all the fk values are valid.
The other note is that generally speaking, all three are basically the
same for the single column key. If you're only doing references on one
column, the match type is mostly meaningless.
> > PENDANT adds that for each row of the referenced table the values of
> > the specified column(s) are the same as the values of the specified
> > column(s) in some row of the referencing tables.
>
> I am not sure I know what you mean here.....Are you saying that the value for
> the FK column must match the value for the PK column?
I haven't really looked at PENDANT, the above was just a small rewrite of
some descriptive text in the sql99 draft I have. There's a whole bunch
of rules in the actual text of the referential constraint definition.
The base stuff seems to be: (Rf is the referencing columns, T is the
referenced table)
3) If PENDANT is specified, then:
a) For a given row in the referencing table, let pendant
reference designate an instance in which all Rf are
non-null.
b) Let number of pendant paths be the number of pendant
references to the same referenced row in a referenced table
from all referencing rows in all base tables.
c) For every row in T, the number of pendant paths is equal to
or greater than 1.
So, I'd read it as every row in T must have at least one referencing row
in some base table.
There are some details about updates and that you can't mix PENDANT and
MATCH PARTIAL or SET DEFAULT actions.
> > The main issues in 7.0 are that older versions (might be fixed in
> > 7.0.3) would fail very badly if you used alter table to rename tables that
> > were referenced in a fk constraint and that you need to give update
> > permission to the referenced table. For the former, 7.1 will (and 7.0.3
> > may) give an elog(ERROR) to you rather than crashing the backend and the
> > latter should be fixed for 7.1 (although you still need to have write
> > perms to the referencing table for referential actions to work properly)
>
> Are the steps to this outlined somewhere then?
The permissions stuff is just a matter of using GRANT and REVOKE to set
the permissions that a user has to a table.
Reference in New Issue View Git Blame Copy Permalink