> 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
> > 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...
In response to
pgsql-hackers by date
|Next:||From: Curt Sampson||Date: 2002-07-31 06:27:41|
|Subject: Re: WAL file location|
|Previous:||From: Thomas Lockhart||Date: 2002-07-31 06:24:33|
|Subject: Re: Open 7.3 items|
pgsql-patches by date
|Next:||From: Thomas Lockhart||Date: 2002-07-31 06:45:49|
|Subject: Re: int64 timestamp patch for contrib/pg_controldata|
|Previous:||From: Tom Lane||Date: 2002-07-31 05:44:06|
|Subject: Re: [HACKERS] DROP COLUMN round 4 |