From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Patches" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] DROP COLUMN round 4 |
Date: | 2002-07-31 06:27:03 |
Message-ID: | GNELIHDDFBOCMGBFGEFOAEHBCDAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> This happens because indexes are marked DEPENDENCY_AUTO on their
> columns. The drop will cascade to the index even under RESTRICT;
> if you have message level set to DEBUG1 or higher you'll be told
> about it, but otherwise the behavior is to zap the index quietly.
Ah doh. I knew that as well. I'll try a view or something then...
> > Note that the check against the parent attribute when adding a
> foreign key
> > probably should be improved. ie. It relies on the fact that the parent
> > column(s) should not have a unique index on them (thanks to
> dependencies),
> > rather than actually checking the attisdropped attribute.
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...
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2002-07-31 06:27:41 | Re: WAL file location |
Previous Message | Thomas Lockhart | 2002-07-31 06:24:33 | Re: Open 7.3 items |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2002-07-31 06:45:49 | Re: int64 timestamp patch for contrib/pg_controldata |
Previous Message | Tom Lane | 2002-07-31 05:44:06 | Re: [HACKERS] DROP COLUMN round 4 |