Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1796086411.1211305915741.JavaMail.jira@brutus>
Date: Tue, 20 May 2008 10:51:55 -0700 (PDT)
From: "Mamta A. Satoor (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1062) Change the internal implemetation of
 SYSCS_INPLACE_COMPRESS_TABLE to share existing alter table
In-Reply-To: <412439192.1141079095096.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598371#action_12598371 ] 

Mamta A. Satoor commented on DERBY-1062:
----------------------------------------

In 10.4, for syscs_inplace_compress_table, we did not convert syscs_inplace_compress_table into an ALTER TABLE statement and hence we did not go through SQL parser processing of schem or table name in ALTER TABLE sql. 

Taking the example provided by Knut, 
call syscs_util.syscs_inplace_compress_table('APP', 'test"table', 1, 1, 1); 
in 10.4, SQL parser simply read the schema name as APP and table as test"table and let the OnlineCompress.compressTable do the validation of schemaname.tablename
In 10.5, we now internally convert call syscs_util.syscs_inplace_compress_table('APP', 'test"table', 1, 1, 1); to
alter table "APP"."test"table" compress inplace purge defragment truncate_end
As can be seen from ALTER TABLE sql above, it is going to result into parsing errors because the " inside the table name has not been escaped. 

The behavior for syscs_inplace_compress_table in 10.5 now matches the behavior for syscs_compress_table. In order to compress the table in example above using syscs_compress_table, you have to give like following in both 10.4 and 10.5
call syscs_util.syscs_compress_table('APP', 'test""table', 1);

So, I agree that "call syscs_util.syscs_compress_table(...)" issued for inplace compress for special characters in schema name or table name has changed between 10.4 and 10.5 for syscs_inplace_compress_table. I think to keep the same syntax between the 2 releases will be pretty tricky with the way we generate ALTER TABLE in 10.5 (SystemProcedure.SYSCS_INPLACE_COMPRESS_TABLE). I would like to know if it would be fine to have this change in SQL syntax between 10.4 and 10.5 for schema and/or table names involving special characters. This will also result in the 2 compress CALLs have the same syntax in 10.5 when dealing with special characters in table name and schema name.

> Change the internal implemetation of SYSCS_INPLACE_COMPRESS_TABLE to share existing alter table
> -----------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1062
>                 URL: https://issues.apache.org/jira/browse/DERBY-1062
>             Project: Derby
>          Issue Type: Improvement
>          Components: Newcomer, SQL, Store
>    Affects Versions: 10.1.3.1
>            Reporter: Mike Matrigali
>            Assignee: Mamta A. Satoor
>            Priority: Minor
>
>  Change the internal implemetation of SYSCS_INPLACE_COMPRESS_TABLE to share existing alter table
> code. One suggested approach is to use the same mechanism as SYSCS_COMPRESS_TABLE. Such
> an implementation would involve:
> o change the parser for alter table to accecpt some internal only syntax for SYSCS_INPLACE_COMPRESS_TABLE
> o change the alter table constant action to get the required information for inplace compress
> o move most of the inplace compress driving code to a routine in alter table execution, following the same
>      coding pattern as existing alter table compress.
> I believe doing this will have multiple benefits:
> 1) shares existing alter table code, so things like error checking, security management, ... is all done by one piece of code
> 2) by sharing the code I believe the following outstanding JIRA issues will be addressed: DERBY-719, DERBY-720 -
> 3) future changes addressing ddl like grant/revoke will automatically work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.