Hi All, Supporting register table/view in CLI (and the setup command) sounds reasonable to me.
Exporting tables/views should probably pair with "register". As for create, I agree that it is beyond the scope of Polaris CLI. If we want to support downloading metadata to local storage for later "re-create from scratch" operations (in a different location), this is probably something that could be supported in the Migrator Tool [1]. I suppose the tool can already perform that by sync'ing to a file-based catalog. However, IIRC, it cannot alter locations by itself. [1] https://github.com/apache/polaris-tools/tree/main/iceberg-catalog-migrator Cheers, Dmitri. On Mon, Sep 14, 2026 at 11:08 AM Jean-Baptiste Onofré <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
