I agree with both Yufei & Dmitri: #1 - It seems like improper coupling for an Iceberg REST Catalog config to return a configuration unrelated to Iceberg. #2 - Polaris is a superset of an Iceberg REST Catalog.
So, in my opinion, the question is more aptly framed as two questions: #1 - Is GET 'http://localhost:8181/api/catalog/v1/config?warehouse=polaris' only an Iceberg Catalog concept? #2 - Should GET ' http://localhost:8181/api/catalog/v1/config?warehouse=polaris' return additional endpoints? I believe that the answer to #1 is no, but that requires changes to the codebase. I believe the answer to #2 is yes. Based on the codebase, we are exposing several endpoints in this configuration API which are not Iceberg endpoints. For example, in the Generic Tables case, it is explicitly not Iceberg. In my opinion, this is alright because our API specification only says "Configuration API," not "Iceberg Configuration API." Yes, it is Iceberg-compatible, but it is not Iceberg-centric. This retrieves the configuration for the Catalog; regardless of whether it is an Iceberg Catalog. Now, if this is truly a superset, it implies that IcebergCatalogHandler.java should not handle returning the configuration. Additionally, we need to return a superset of the ConfigResponse (an Iceberg-core concept) for the REST API response. Now, if the answer to #1 is yes, that means we should probably have a separate API for configuration. What do y'all think? Go community, Adam On Mon, Jun 22, 2026 at 1:55 PM Yufei Gu <[email protected]> wrote: > I think a Polaris client is also an IRC client, just with additional > capabilities. In that sense, Polaris can be viewed as a superset of IRC. If > the config endpoint is intended for capability discovery, returning Polaris > specific endpoints seems reasonable. Standard IRC clients can simply ignore > endpoints they don't recognize. > > A concrete example is the Polaris Spark client, which checks server > capabilities before using Polaris specific functionality: > > public List<TableIdentifier> listGenericTables(Namespace ns) { > Endpoint.check(endpoints, PolarisEndpoints.V1_LIST_GENERIC_TABLES); > > > Yufei > > > On Fri, Jun 19, 2026 at 7:43 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi All, > > > > During my review of [4816] I realized [1] that Polaris returns some > non-IRC > > endpoints in the IRC config responses. > > > > For example: > > > > GET 'http://localhost:8181/api/catalog/v1/config?warehouse=polaris' > > > > Result: > > [...] > > "endpoints": [ > > "GET /v1/{prefix}/namespaces", > > "GET /v1/{prefix}/namespaces/{namespace}", > > "HEAD /v1/{prefix}/namespaces/{namespace}", > > [...] > > "DELETE > > > polaris/v1/{prefix}/namespaces/{namespace}/generic-tables/{generic-table}", > > "GET > > > polaris/v1/{prefix}/namespaces/{namespace}/generic-tables/{generic-table}", > > "GET /polaris/v1/{prefix}/namespaces/{namespace}/policies", > > "POST /polaris/v1/{prefix}/namespaces/{namespace}/policies", > > > > The latter group of endpoints is not related to the Iceberg REST Catalog > > API. > > > > I wonder what the rationale might be for returning them in the IRC config > > response. > > > > From my POV, returning them in the IRC config response is incorrect > because > > these endpoints form APIs that follow a different specification and > clients > > using the IRC API do not need that information to properly use the IRC > API. > > > > WDYT? > > > > [1] https://github.com/apache/polaris/pull/4816#discussion_r3438945230 > > > > [4816] https://github.com/apache/polaris/pull/4816 > > > > Thanks, > > Dmitri. > > >
