Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of msatoor@gmail.com designates
 66.249.82.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=HAM/eAUNNPPAFDOvb23vOxYRuPdQH37a8l7W42DUIYq/6xxZ8tNkieERRSLM9EnPYpKzACWOnk/yRlQZsoHlXTMW2Vkf9NO7RfV8UeolDtwAaVkh/ekv+/pUEa5eCW77Stx+jBK/BcJd+VO5yjDxce2OOrPuZH1KJHfnKaksDxM=
Message-ID: <d9619e4a0607141041u32f173a0w2cc6b9f17ed865d7@mail.gmail.com>
Date: Fri, 14 Jul 2006 10:41:44 -0700
From: "Mamta Satoor" <msatoor@gmail.com>
To: derby-dev@db.apache.org
Subject: Re: DERBY-396: Drop Column dependency questions
In-Reply-To: <44B7CAB9.3060709@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_20229_29174491.1152898904812"
References: <1516417.1152061955352.JavaMail.jira@brutus>
	 <44AC9374.8090304@amberpoint.com> <44B283E4.5090504@sun.com>
	 <d9619e4a0607140915u19d2cdb8i316ced02cfa700d9@mail.gmail.com>
	 <44B7C722.4000102@amberpoint.com> <44B7CAB9.3060709@apache.org>

------=_Part_20229_29174491.1152898904812
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think in RESTRICT mode, revoking the privileges should be done as one of
the last steps, ie after we have checked for dependent objects. If there are
dependent objects. DROP COLUMN RESTRICT will fail. If there are no dependent
objects, then revoke privileges should simply work because there couldn't be
any objects dependent on those privileges at this point in the code. And I
tend to agree with Dan that DROP COLUMN RESTRICT shouldn't throw exception
just because there are privileges granted on it. If there are no objects
based on those privileges, it should be fine to REVOKE them. But, I haven't
looked at the spec to verify this behavior.

Mamta


On 7/14/06, Daniel John Debrunner <djd@apache.org> wrote:
>
> Bryan Pendleton wrote:
>
> > Hi Mamta, thank you for investigating this.
> >
> >> DROP COLUMN will also need to see if there are any privileges granted
> >> on it and if yes, then those privileges should be revoked.
> >
> >
> > That makes sense to me, too.
> >
> > I am proposing to have the ALTER TABLE DROP COLUMN statement call the
> > already-existing code in AlterTableConstantAction.java, specifically
> > the dropColumnFromTable() method.
> >
> > I am proposing to implement both CASCADE and RESTRICT, using the
> existing
> > cascade/restrict functionality in the dropColumnFromTable() method.
> >
> > So I think that we just need to add the appropriate code to this method
> > for privileges, and then we should be fine. It sounds like we need some
> > code which looks for privileges granted on this column, and if there are
> > any, then if this is RESTRICT, throw an exception, otherwise
> automatically
> > revoke those privileges.
>
> I don't think that matches the SQL spec. From a quick look I don't see
> any text that stops the drop in restrict mode if privileges have been
> granted on the column.
>
> Dan.
>
>

------=_Part_20229_29174491.1152898904812
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>I think in RESTRICT mode, revoking the privileges should be done as one of the last steps, ie after we have checked for dependent objects. If there are dependent objects. DROP COLUMN RESTRICT will fail. If there are no dependent objects, then revoke privileges should simply work because there couldn't be any objects dependent on those privileges at this point in the code. And I tend to agree with Dan that DROP COLUMN RESTRICT shouldn't throw exception just because there are privileges granted on it. If there are no objects based on those privileges, it should be fine to REVOKE them. But, I haven't looked at the spec to verify this behavior.
</div>
<div>&nbsp;</div>
<div>Mamta<br><br>&nbsp;</div>
<div><span class="gmail_quote">On 7/14/06, <b class="gmail_sendername">Daniel John Debrunner</b> &lt;<a href="mailto:djd@apache.org">djd@apache.org</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Bryan Pendleton wrote:<br><br>&gt; Hi Mamta, thank you for investigating this.<br>&gt;<br>&gt;&gt; DROP COLUMN will also need to see if there are any privileges granted
<br>&gt;&gt; on it and if yes, then those privileges should be revoked.<br>&gt;<br>&gt;<br>&gt; That makes sense to me, too.<br>&gt;<br>&gt; I am proposing to have the ALTER TABLE DROP COLUMN statement call the<br>&gt; already-existing code in 
AlterTableConstantAction.java, specifically<br>&gt; the dropColumnFromTable() method.<br>&gt;<br>&gt; I am proposing to implement both CASCADE and RESTRICT, using the existing<br>&gt; cascade/restrict functionality in the dropColumnFromTable() method.
<br>&gt;<br>&gt; So I think that we just need to add the appropriate code to this method<br>&gt; for privileges, and then we should be fine. It sounds like we need some<br>&gt; code which looks for privileges granted on this column, and if there are
<br>&gt; any, then if this is RESTRICT, throw an exception, otherwise automatically<br>&gt; revoke those privileges.<br><br>I don't think that matches the SQL spec. From a quick look I don't see<br>any text that stops the drop in restrict mode if privileges have been
<br>granted on the column.<br><br>Dan.<br><br></blockquote></div><br>

------=_Part_20229_29174491.1152898904812--