Re: [HACKERS] DROP COLUMN round 4 - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] DROP COLUMN round 4
Date
Msg-id 14167.1028313916@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] DROP COLUMN round 4  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-patches
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> OK, in this statement:

> ALTER TABLE child ADD FOREIGN KEY (a) REFERENCES parent(b);

> It does not check that column b is not dropped (it does check "a").  It just
> relies on the UNIQUE constraint not being present on b.  This should
> probably be fixed...

This is not really a case of it "relies on" that, it's just that the
check for a key is done before trying to resolve the column names to
numbers, so you get that error first.  I'm not sure it's worth trying to
rearrange the code in analyze.c to avoid that.  In the self-referential
case,

    create table foo (id int primary key,
              parent int references foo);

you more or less have to work with column names not numbers.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] DROP COLUMN round 4
Next
From: Bruce Momjian
Date:
Subject: Re: Improve CHECK failure message