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.
>
