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 > > > > > > > > > > > > > > >
