wangyum commented on code in PR #6888:
URL: https://github.com/apache/hive/pull/6888#discussion_r4310559757
##########
standalone-metastore/metastore-server/src/main/java/org/apache/hadoop/hive/metastore/HMSHandler.java:
##########
@@ -1577,6 +1577,10 @@ public GetPartitionsResponse
get_partitions_with_specs(GetPartitionsRequest requ
getTableRequest.setCatName(catName);
Table table = get_table_core(getTableRequest);
firePreEvent(new PreReadTableEvent(table, this));
+ // Perform the same table-level filter hook check the regular partition
listing RPCs
+ // perform in GetPartitionsHandler.authorizeTableForPartitionMetadata()
+ FilterUtils.checkDbAndTableFilters(isServerFilterEnabled, filterHook,
normalizeIdentifier(catName),
Review Comment:
One more reason this consistency matters: Apache Spark is about to start
relying on `getPartitionsWithSpecs` more heavily. See apache/spark#58984, which
switches write (`InsertIntoHadoopFsRelationCommand`), truncate
(`TruncateTableCommand`), repair (`RepairTableCommand`), and metadata-only
query call sites to a new `listPartitionLocations` API backed by this exact RPC
(`Shim_v4_0` on Hive 4+).
Those are write/DDL-adjacent code paths, not just read-only listing — so
it's important that `getPartitionsWithSpecs` enforces the same table-level
filter-hook check as every other partition-listing RPC. If this RPC behaved
differently (e.g. silently returning an empty/partial result instead of failing
with `NoSuchObjectException` when the caller shouldn't even see the table),
Spark callers built on top of it could end up with inconsistent or unsafe
behavior for users who are supposed to be filtered out. Keeping this check in
place is what lets downstream consumers like Spark adopt the API with
confidence that it behaves the same as the rest of the partition-listing
surface.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
