Hi Yufei, Thanks for context!
Re: the current description for "unique-table-location" [1], it states: "Whether to use a unique location for new tables". I find this statement totally confusing. Who is supposed to generate this unique location? When? Do you have any insight into how this property was envisioned to be used in practice? [1] https://iceberg.apache.org/docs/latest/catalog-properties/#common-properties Thanks, Dmitri. On Thu, Jun 4, 2026 at 2:12 PM Yufei Gu <[email protected]> wrote: > 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 >
