Aleksandr Efimov created IMPALA-15320:
-----------------------------------------

             Summary: Bring MERGE, UPDATE, DELETE and OPTIMIZE under 
checkTableCapability()
                 Key: IMPALA-15320
                 URL: https://issues.apache.org/jira/browse/IMPALA-15320
             Project: IMPALA
          Issue Type: Improvement
          Components: Frontend
            Reporter: Aleksandr Efimov
            Assignee: Aleksandr Efimov


Analyzer.checkTableCapability() is where a statement asks whether a table 
supports what it is about to do, but only InsertStmt, AlterTableStmt, 
DropTableOrViewStmt, LoadDataStmt, TruncateStmt and BaseTableRef go through it. 
MergeStmt, ModifyStmt and OptimizeStmt write to a table without ever asking.

IMPALA-15310 needs such a check on those three, to refuse everything but INSERT 
INTO on an Iceberg table loaded from a REST catalog, and had to add a 
hand-written call to each of them rather than a case in checkTableCapability(). 
A new DML statement, or a new path into an existing one, now has to remember 
that call, and nothing points that out until the statement fails somewhere 
further down.

Routing the three through checkTableCapability(WRITE) is the fix, and it is not 
a no-op: they would start running what ensureTableWriteSupported() applies, 
which is the bucketed-table check plus the HMS access-type check for everything 
except Kudu, or the transactional-table check on Metastore 2. That is a 
behaviour change for statements that have never run it, so it wants its own 
patch and its own testing rather than riding along with a REST catalog change.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to