Hi Yong, I agree with starting on `tables` / `views` before `setup`, and with keeping create out of long CLI flags. I would split register and create, though :) they solve different problems.
Register is the piece that unblocks the discussion. The server already has Iceberg REST register / register-view; the CLI just does not expose them. Name + metadata location (the metadata.json, not a manifest) is a natural command, and it is the right apply primitive for setup, export identifier + location, apply via register. That preserves existing history. Create would mint a new table/view, which is not what operators asked for in https://github.com/apache/polaris/discussions/5481. Create can come later, from an input file the way `policies create --policy-file` works. Prefer Iceberg REST CreateTableRequest / CreateViewRequest JSON over a new schema dialect. Views are tractable; tables are still messy, just in a file. Engines already create well, so I would not gate register or setup on this. On pyiceberg: I would not adopt their CLI. It has no create-table or register today, and Polaris CLI is an admin tool (profiles, privileges, policies, setup) with a different auth story. The generated Iceberg REST client we already use for list/get/drop is enough for register, and for create-from-JSON later. Using pyiceberg as a library would be a new runtime dependency; worth revisiting only if we want a friendlier schema than REST JSON. Once register exists, setup should export/apply tables and views that way, and also table/view privileges. `polaris privileges table|view grant` already works, but setup export skips those grants and apply currently warns and ignores them. That is the other half of https://github.com/apache/polaris/discussions/5481. Does that sequencing feel right? register first, then setup + table/view grants, then optional file-based create? WDYT? Thanks, Prithvi S On Sun, Sep 13, 2026 at 8:05 AM Yong Zheng <[email protected]> wrote: > Hello, > > Recently we got a discussion from community where people are looking for > additional tables/views management in Polaris CLi: > https://github.com/apache/polaris/discussions/5481 > > From the request, community would like to support tables/views creation > via `setup` command. We already have some supports around tables/views in > existed polaris CLI and here are what we supported as of today: > > Tables: > 1. list > 2. get > 3. summarize > 4. delete (de-register) > > Views: > 1. list > 2. get > 3. summarize > 4. delete > > So to support the requested feature, we will need to support at least > "register" and "create" for both tables and views. Lets start focus on > standard "tables" and "views" commands before we go over "setup" command > which is what been requested. > > For register support in "tables" and "views" commands, this is easy to > implement as we will just need users to provide the target view name and > manifest location. This is very nature imo via CLI. For the record, this is > not something pyiceberg support via CLI as well. > > For create support in "tables" and "views" commands, this is where things > can be a bit messy especially for views. Lets break down on what does it > takes for us to support this. Same as register, this is not something > pyiceberg support via CLI as well. > > Create view support: > For this one, we would only need a view parameters such as sql type, sql > itself, dialect, and couple metadata such as engine name and engine > version. However, this is about 5-6 extra parameters that we would need to > support in CLI to be able to support this. We would do similar route with > policy creation where we would ask user to pass in an input file that > contains those content to avoid lengthy command. > > Create table support: > For this one, this is where things can be very messy IMO. Unlike create > view, create table can be a lot more complex as we will need to provide a > lot more info such as schema, partition spec, sort order. The most > problematic part would be schema as it can be very complex and nested. > Personally, I don't think this is something we should support via CLI > unless this is layout in an input file (similar to policy). > > Now back to adding the request support, I do think this is do-able but we > should avoid pass-in length arguments for the command. Instead, we should > support those operations via input file instead (match to how we are > creating policy). > > Lastly, we can write our own modules for those as how we are doing those > for the existed commands around tables/views commands. I am wondering if we > should consider adopt pyiceberg into polaris cli and use their SDK instead > of reinventing the wheels here. > > What do you think? Is this something we are planning to support? > > Thanks, > Yong > > > > > > >
