Re: [HACKERS] DROP COLUMN round 4

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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