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]