Skip site navigation (1) Skip section navigation (2)

Possible bug in FOREIGN KEY

From: Michael J Schout <mschout(at)gkg(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Possible bug in FOREIGN KEY
Date: 2000-07-28 00:10:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
(sorry for sending this 2x.  I accidently omitted the Subject on the first


Didn't know if this is a known issue or not, but  I think the following ought to fail, and it does not:

mschout=# create table foo (f1 int not null, primary key (f1));
NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index 'foo_pkey' for table 'foo'

so far, so good.

now the problem:

create table bar (
    f2 int not null,
    foreign key (blah) REFERENCES foo (f1) ON DELETE RESTRICT

I think this *should* fail since "blah" isn't defined in the table anywhere.

the result:
NOTICE:  CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)

Note that column "blah" doesnt actually exist.  Shouldn't we complain and bail
out from the create in this case?  A typeo in a FOREIGN KEY clause would bypass
the restriction altogether. 

The only reason I can think where this might be desired is if the table created
INHERITS some other table (that might have column "blah" in it).  Maybe there
is some easy way to check that though?

This is on postgreSQL 7.0.2, Redhat Linux 6.2

Anyways, figured I better report this in case its not a known issue :)


pgsql-hackers by date

Next:From: Philip WarnerDate: 2000-07-28 00:58:48
Subject: pg_dump and ANSI types (TODO item)
Previous:From: Michael J SchoutDate: 2000-07-28 00:07:35

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group