Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

Next:From: Curt SampsonDate: 2002-07-31 06:27:41
Subject: Re: WAL file location
Previous:From: Thomas LockhartDate: 2002-07-31 06:24:33
Subject: Re: Open 7.3 items

pgsql-patches by date

Next:From: Thomas LockhartDate: 2002-07-31 06:45:49
Subject: Re: int64 timestamp patch for contrib/pg_controldata
Previous:From: Tom LaneDate: 2002-07-31 05:44:06
Subject: Re: [HACKERS] DROP COLUMN round 4

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group