Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: 32.97.110.154 is neither permitted nor
 denied by domain of bandaram@gmail.com)
Message-ID: <44ADB189.2050007@gmail.com>
Date: Thu, 06 Jul 2006 17:57:45 -0700
From: Satheesh Bandaram <bandaram@gmail.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: DERBY-396: Drop Column dependency questions
References: <1516417.1152061955352.JavaMail.jira@brutus>
 <44AC9374.8090304@amberpoint.com>
In-Reply-To: <44AC9374.8090304@amberpoint.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Bryan,

Thanks for working on this long requested feature. More below...

Bryan Pendleton wrote:

>
> Does it seem correct that:
>
> a) RESTRICT processing should consider an index on a column to be
> a dependent object and fail the DROP COLUMN if the column is used
> in an index?

What happens when you drop a column with restrict that is part of a
composite index? How about if there are any constraints on that column?
Also have to worry about that being a triggering column or part of
trigger body.

I personally prefer if DROP COLUMN also implicitly drops an index on
that column, even for RESTRICT. It should also be able to drop a default
and any constraints that affect only that column. (though not sure if
there is a primary key on that column)

> b) CASCADE processing should cascade the DROP COLUMN to include
> dropping a view which uses the column that is dropped?
>
Derby doesn't support CASCADE option for any DDLs that I am aware of.
Like dropping a table with CASCADE option or dropping a schema with
CASCADE option to drop dependent objects. I wouldn't implement CASCADE
option only for DROP COLUMN... that probably depends on real cascade
implementation underneath it. Also would raise lots of questions about
what else you should drop... like constraints, triggers, composite
indexes etc...

Satheesh

> thanks,
>
> bryan
>
>