Hi Bill, This proposal looks very useful to me.
I think it's a natural tool to add to Polaris. You'll notice, for example, that Nessie has a similar shell [1] Just to confirm (I haven't looked at the code :) ) - the tool communicates with Polaris via REST APIs, right? In terms of practical steps, I tend to think that this shell fits well into the Polaris Tools repo [2]. A simple PR should be fine for a start. I do not think we need much process (beyond the usual review) for adding a new tool. Having a rich README file (or similar) in the PR will probably be more useful than a proposal doc in this case (since you already have the code written down). [1] https://projectnessie.org/nessie-latest/cli/ [2] https://github.com/apache/polaris-tools/ Cheers, Dmitri. On Thu, May 7, 2026 at 9:32 PM Bill Bejeck <[email protected]> wrote: > Hi all, > A while back, someone raised on this list > (https://lists.apache.org/thread/35zzzh2jgorhx7q2xksp7rwxnt6gl2zx) that > once Polaris is bootstrapped, simple operational questions ("how many > tables in > this namespace?", "how many snapshots?", "any small files?") > force you to switch to Spark/Trino/pyiceberg and write a script. > It gave me an idea for a standalone SQL > shell (ANTLR grammar + REST catalog client, ships as a shadow jar). > Code: > > > https://github.com/bbejeck/polaris/tree/add-sql-module/extensions/sql-engine > End-to-end > <https://github.com/bbejeck/polaris/tree/add-sql-module/extensions/sql-engineEnd-to-end> > demo (docker-compose + MinIO, runs locally): > > > https://github.com/bbejeck/polaris/tree/add-sql-module/extensions/sql-engine/demo > It adds Iceberg-aware statements like > SHOW TABLES, DESCRIBE STATS, SHOW TABLE LOCATION/POLICIES, > DIAGNOSE TABLE, and EXPLAIN so you can poke at namespaces, > snapshots, small-file diagnostics, etc., without firing up Spark or Trino. > The demo above spins up Polaris + MinIO, seeds three Iceberg tables, and > lets you try > all of the statements above in a few minutes. > A few things worth stating upfront, because the "yet another SQL > dialect" worry is real: > - Not trying to compete with Spark/Trino/Doris SQL > - The SELECT support is "peek at a table from the shell", not > "run analytics". > - Dialect baseline I'd propose: small SQL-92 read-only subset > plus a handful of named Polaris extension statements > (DESCRIBE STATS, DIAGNOSE TABLE, etc.). Easy to maintain, > intentionally orthogonal to the engines. > > If anyone thinks this could be useful, I'd love to discuss the next steps. > I'm new to the Polaris community, but I know in Apache Kafka, something > like this would require a KIP, > so I'm also willing to do a more formal design doc. > Thanks, > — Bill Bejeck >
