Hi folks, While reviewing the recently opened issue( https://github.com/apache/polaris/issues/4492) around `unique-table-location` support, I read through the original Iceberg discussion and implementation. My understanding is that `unique-table-location` was introduced as an impl-level catalog property to address location management concerns in specific catalog implementations such as the JDBC Catalog, Hive Catalog, and Glue Catalog. It was primarily intended to help those catalogs generate unique table storage locations and avoid collisions. Given that, I don't believe this property should be part of the REST Catalog contract between clients and servers.
Polaris is a REST catalog service with its own location management semantics. Unlike other built-in Iceberg catalog implementations, Polaris is not simply exposing the default Iceberg catalog behavior. In my view, location management should remain a server side concern, and Polaris should be opinionated about how table locations are assigned and managed. Because of that, I am hesitant to expose or honor `unique-table-location` as a user-visible catalog property. Doing so would effectively make an implementation detail part of the Polaris API surface. Before we proceed with adding support, I'd like to hear whether others agree that: 1. `unique-table-location` is an implementation specific configuration rather than a REST catalog protocol requirement. 2. Polaris should retain ownership of location management semantics. 3. Compatibility with Iceberg's catalog test suite alone may not be sufficient justification for exposing this property. Here is a caveat: the property is documented in common catalog properties [1], and REST /v1/config uses generic config maps that can carry arbitrary catalog keys, even though IRC doesn't mention it at all. We may document it in Polaris to eliminate confusion. Interested in hearing other opinions. 1. https://iceberg.apache.org/docs/latest/catalog-properties/#common-properties Thanks, Yufei
