Arun, Manually running DDL against the SYSTEM.CATALOG table can be problematic for a few reasons: - if a write failure occurs in the middle of running that statement, your SYSTEM.CATALOG table can be left in an inconsistent state. We prevent this internally by using a mutateRowsWithLocks call which has an all or none commit behavior. - if another client is doing another operation on the view, such as altering it or an operation on the underlying table (cascade drop), then there will be no locking on the view row to prevent interleaved mutations. - the above DELETE statement would be a full table scan as you're not constraining the leading two PK columns (i.e. where clause should have TENANT_ID is null AND TABLE_SCHEM is null) assuming your base table is not a multi-tenant table.
FWIW, we plan to start a vote on a 4.5.0 release in a week which will have a fix for this issue. Thanks, James On Mon, Jun 22, 2015 at 8:36 AM, Arun Kumaran Sabtharishi <[email protected]> wrote: > James, > > Do you see any issues in using the delete statement below as a workaround > for dropping views until the JIRA's are fixed and released? > > delete from SYSTEM.CATALOG where table_name = 'MY_VIEW' > > Thanks, > Arun
