Hi All, A REPL shell has its advantages and may be preferable to running individual CLI commands at the shell level for some users.
I guess Bill proposes a REPL shell, if I understand correctly. We could extend the Python CLI with REPL capabilities, but this would require converting Bill's code to Python. If it works in practice, why not? However, if it's an obstacle, I'd rather Bill contributed a Java REPL to polaris-tools. Other users would then be able to try the REPL shell and provide feedback, which we could use to define the future direction of CLI evolution. Adding similar features to the Web UI would be nice (as JB suggested), of course, but I still expect a certain class of users to gravitate towards the textual UI. Cheers, Dmitri. On Mon, May 11, 2026 at 1:20 PM Yufei Gu <[email protected]> wrote: > Hi Bill, all, > > Thanks for raising this. I'd suggest enriching the Polaris CLI as much as > possible, > https://polaris.apache.org/releases/1.4.1/command-line-interface/. > Yong has been working on it for a while now. The CLI should be generally > good enough for most use cases. We should also try to avoid file IO if > possible as I mentioned in this thread [1]. That should avoid turning this > into a competing SQL engine while still solving the operational > quick-inspection use case. > > 1. https://lists.apache.org/thread/35zzzh2jgorhx7q2xksp7rwxnt6gl2zx > > Yufei > > On Sun, 10 May 2026 07:47:41 +0200, “Jean-Baptiste Onofré” [email protected] > wrote: > > Hi Bill, > > Great proposal! > > Exposing new features on top of the Polaris REST APIs is always welcome and > helpful. I agree that this is a strong candidate for the polaris-tools > repository. Additionally, we might want to consider incorporating similar > operational metrics into the Polaris Console (I will move forward on > Polaris Console release after Polaris 1.5.0). > > Thanks! > > Regards, > JB > > On Fri, May 8, 2026 at 3:32 AM 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> > > 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 >
