[
https://issues.apache.org/jira/browse/IMPALA-15320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Efimov resolved IMPALA-15320.
---------------------------------------
Fix Version/s: Impala 5.0.0
Resolution: Fixed
> 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
> Priority: Major
> Labels: impala-iceberg
> Fix For: Impala 5.0.0
>
>
> 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)
