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 <[EMAIL PROTECTED]> 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.
