IMHO that property is for client based catalogs and not rest ones. We should always be making unique names unless expressly asked not to.
On Thu, Jun 4, 2026 at 12:23 PM Yufei Gu <[email protected]> wrote: > 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 > > > > > >
