From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Hannu Krosing" <hannu(at)tm(dot)ee>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DROP COLUMN Proposal |
Date: | 2002-07-01 15:19:28 |
Message-ID: | 008501c22112$b1f02af0$0200a8c0@SOL |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> This part should fall out of Rod Taylor's pg_depend stuff pretty easily.
> We still need to debate about the behavior, though. If for example there
> is a unique index on column B, do you need "DROP B CASCADE" to get rid
> of it, or is "DROP B RESTRICT" good enough? Does your answer change if
> the unique index is on two columns (A,B)? I'm not real sure where the
> boundary is between attributes of the column (okay to drop as part of
> the column) and independent objects that ought to be treated as
> requiring CASCADE.
>From SQL92:
"If RESTRICT is specified, then C shall not be referenced in
the <query expression> of any view descriptor or in the <search
condition> of any constraint descriptor other than a table con-
straint descriptor that contains references to no other column
and that is included in the table descriptor of T."
So I guess that means that if the unique index is only on the dropped
column, then restrict mode will still be able to drop it...
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Koizar | 2002-07-01 15:35:54 | Re: [PATCHES] Reduce heap tuple header size |
Previous Message | Christopher Kings-Lynne | 2002-07-01 15:00:30 | Re: [PATCHES] Changes in /contrib/fulltextindex |