| 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: | Whole Thread | Raw Message | 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 |