Hi Dmitri, Thanks for the reply. I'm glad you can see the utility.
Just to confirm (I haven't looked at the code :) ) - the tool communicates > with Polaris via REST APIs, right? Yes, under the covers, it's using the Polaris REST API. 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). That works for me, I'll start on that this weekend. Thanks again, Bill On Fri, May 8, 2026 at 11:58 AM Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > >
