Thanks for the feedback. Here is the PR for adding this supports to tables/views commands: https://github.com/apache/polaris/pull/5577
Once merged, i will work on the change for the setup command. Thanks, Yong On 2026/09/14 16:31:45 Yufei Gu wrote: > I think the use cases discussed in > https://github.com/apache/polaris/discussions/5481 would be achieved by > adding support for table/view registration. > > Do we have a use case for creating tables via the CLI? > > Yufei > > > On Mon, Sep 14, 2026 at 8:33 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
