Re: DROP COLUMN Proposal

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

In response to

Browse pgsql-hackers by date

  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