Ditto to Yufei and JB. Yong, I believe Polaris-Iceberg interoperability currently centers mainly on the Iceberg REST Catalog interface integration paradigm. My 2 cents: until Polaris decides to move to a different paradigm, we should not ad-hoc poke around Iceberg through different channels.
-ej On Mon, Feb 23, 2026 at 9:42 PM Jean-Baptiste Onofré <[email protected]> wrote: > Hi Yong, > > It's a great idea ! > > I would keep the CLI as close to REST API as possible. If we start to have > the CLI depending on other parts (like filesystem), I will probably face > some challenges like permissions, isolation concern. > If we expose some "statistics" in the REST API and CLI use it, it makes > sense, but we should not couple CLI and filesystem. > > Regards > JB > > On Sat, Feb 21, 2026 at 7:57 AM Yong Zheng <[email protected]> wrote: > > > Hello, > > > > The current CLI is primarily used to interact with various entities in > > Iceberg. Oftentimes, the CLI itself is not very handy after the initial > > bootstrap or after entity modification. For example, if I need to look up > > how many tables there are under a given namespace or the number of > > snapshots a given table has, I would need to switch to a different tool > > (e.g., pyiceberg, Trino, Spark) to write some queries or run some > > predefined scripts to obtain this information. Thus, I am wondering if we > > should enrich the current CLI with a bit more functionality around > > statistics to fulfill the following more use cases such as: > > 1. Number of tables under a given namespace > > 2. Table metadata statistics report (number of snapshots, snapshot size, > > number of partitions, etc.) > > 3. Table storage location and size > > 4. Table current effective policies > > 5. Table diagnostics (e.g., too many small files) > > > > Thanks, > > Yong Zheng > >
