Hey guys +1 for the sequencing: register -> setup export/apply + table/view grants -> optional file-based create.
I checked in the code, and it's maybe easier than it might look: 1. registerTable/registerView are already in spec/iceberg-rest-catalog-open-api.yaml and already implemented server-side (IcebergCatalogAdapter). Since the CLI IcebergCatalogAPI client is generated straight from the spec, the register methods should already exist in the generated client. This is likely just wiring a register subcommand into tables.py/views.py next to the existing list/get/delete/summarize, no server or SDK work needed. 2. _create_catalog_roles in setup.py explicitly detects table/view privileges and warns that they are ignored, and there's no table/view export at all. So that's a well-scoped follow-up once register lands. 3. Regarding pyiceberg, I'm not convinced we should adopt it. It's already a dependency, but scoped only to integration tests. It's never used by the CLI commands themselves. Pulling it ino the CLI "runtime" would be a new surface area rather than reuse, and it doesn't even solve the problem since pyiceberg own CLI has no register/create-table today either. So, I think with register support for tables/views, we would have something "clean". Regards JB On Mon, Sep 14, 2026 at 5:18 AM Yong Zheng <[email protected]> wrote: > > Hello Prithvi, > > The plan sounds good to me and thanks highlight the map around privileges > gaps on tables/views with existed setup command. I will work on register then > the grants in the upcoming weeks while waiting for more feedback from > community around this topic. > > Thanks, > Yong > > On 2026/09/13 11:54:56 Prithvi S wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > >
