db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1909) ALTER TABLE DROP COLUMN needs to update GRANTed column privileges
Date Thu, 28 Dec 2006 16:56:23 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1909?page=all ]

Bryan Pendleton updated DERBY-1909:
-----------------------------------

    Attachment: rewrite_syscolperms_v1.stat
                rewrite_syscolperms_v1.diff

Attached is rewrite_syscolperms_v1.diff, a proposed patch for this problem.

The core of this proposed patch involves refactoring and reusing the
DERBY-1847 method which knows how to rewrite SYSCOLPERMS rows
to update the COLUMNS column. The DERBY-1847 version of that code
only handled the case of adding a bit to the COLUMNS column; this patch
extends that method to support removing a bit from the COLUMNS
column as well, then calls the method from the AlterTable execution logic.

The diff file is rather large because because it includes the removal of
altertableDropColumn.sql and altertableDropColumn.out, and the
merging of those files into altertable.sql and altertable.out, so the
entire contents of those files are included in the diff twice each :)

The rest of the diff is pretty small and straightforward and hopefully is
not hard to review.

The diff includes the proposed 2-line change from DERBY-1847, because
that change is mandatory for this fix. Once the DERBY-1847 change is
resolved, I'll revisit this diff to remove those two lines from DataDictionaryImpl.java

The proposed patch has one particularly interesting behavior: in the case
in which a column is dropped from a table, and there exists a user who
was granted privileges on that column, and that column only, in that table,
the diff processes their SYSCOLPERMS row and leaves a "empty" row; that
is, a row in which the COLUMNS column of SYSCOLPERMS has all bits clear.
>From what I can tell, this does not cause any problems; the behavior is
reasonable. However, it might be argued that it would be preferable to
entirely delete the row in this case. Feedback from reviewers about this
behavior and about how to address it (if necessary), would be much appreciated.


> ALTER TABLE DROP COLUMN needs to update GRANTed column privileges
> -----------------------------------------------------------------
>
>                 Key: DERBY-1909
>                 URL: http://issues.apache.org/jira/browse/DERBY-1909
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Bryan Pendleton
>         Assigned To: Bryan Pendleton
>         Attachments: d1909_partial_incomplete.diff, repro.sql, rewrite_syscolperms_v1.diff,
rewrite_syscolperms_v1.stat
>
>
> When ALTER TABLE DROP COLUMN is used to drop a column from a table, it needs to update
the GRANTed column privileges on that table.
> The following behaviors need to be provided:
> - DROP COLUMN needs to automatically revoke any privileges which have been granted on
this column
> - Privileges which have been granted on other columns in this table need to be adjusted
due to changed column position numbers
> When this problem is fixed, the following additional cleanup steps should occur:
> - The check that disables DROP COLUMN in sqlAuthorization mode needs to be removed
> - There is a comment in AlterTableConstantAction that needs to be revised
> - The tests in lang/altertableDropColumn.sql should be moved into altertable.sql
> - altertableDropColumn.sql and altertableDropColumn.out should be deleted
> Search for this JIRA issue number in the code to find the relevant places to change.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message