If you look at Icebrerg catalogs other than an IRC like Polaris, location creation and metadata.JSON writing is purely client-side behavior.
Yufei On Thu, Jun 4, 2026 at 12:09 PM Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > >
