Hi Yun, I suppose this proposal is going to add a spec to Polaris docs or Open API yaml defining how the credential properties will need to be interpreted by clients.
With such a spec clearly defining the config names for Polaris Generic Tables, I do not see a problem with reusing the same property names as existing Iceberg clients assume. I'd suggest not referencing Iceberg directly, but providing a native spec on the Polaris side to avoid confusion between Iceberg tables and Generic Tables (especially considering that these config entries are not well-defined on the Iceberg side). Similarly, I suppose Polaris will provide Open API structures for the objects representing vended credentials in its own spec. Does that sound reasonable? Thanks, Dmitri. On Mon, Feb 9, 2026 at 1:18 PM yun zou <[email protected]> wrote: > Hi Dmitri and JB, > > Thanks a lot for the valuable feedback! > > > >> How are clients supposed to know the meaning of credential properties in > the "config" section? > > This is a good point. Currently, the Iceberg specification does not provide > a clear definition of these configurations, and the existing documentation > may also be outdated. As Jack suggested, we can provide clear documentation > in Polaris to explain the built-in configuration support. Gravitino follows > a similar approach (see: > https://gravitino.apache.org/docs/next/security/credential-vending). > > > Regarding reusing the same StorageCredential definition as Iceberg, I do > not see this as an antipattern. Generic Table represents a new set of APIs > compared to Iceberg and has the flexibility to evolve independently. > However, reusing definitions for common concepts—such as namespaces and > table identifiers—is reasonable. This helps maintain consistency within > Polaris and lowers the adoption barrier for clients already familiar with > Iceberg. > > > For credential vending in particular, this concerns cloud storage > credential configurations, which are fundamentally the same regardless of > whether the table format is Iceberg or Generic Table. The existing Iceberg > StorageCredential definition is simple and sufficiently flexible to cover > common scenarios, including S3 secret key credentials, S3 token > credentials, ADLS token credentials, and others. It can also be easily > extended to support new credential types introduced by cloud > providers. Therefore, > I believe it is reasonable and beneficial for Generic Table to adopt the > same concept as Iceberg. > > > Best Regards, > > Yun > > On Fri, Feb 6, 2026 at 11:50 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi Yun > > > > At first glance, the proposal looks reasonable to me. It seems that a > large > > part of the "logic" is on the client side, interpreting the > > storage-credentials properties. > > That's OK for me because that's the purpose of Generic Table: a kind of > > "storage" for other table formats (non Iceberg) where the clients have to > > "interpret". > > > > However, I'm a bit confused: the purpose of Generic Table is to support > non > > Iceberg table formats (as stated earlier). If we "couple" the Generic > Table > > with Iceberg, it looks anti-pattern and not aligned with the purpose of > > Generic Table. I think it would be very confusing for Generic Table > > "integrators" and "users" and create "dependencies" to Iceberg (if I want > > to use Delta or Hudi, I don't want to use Iceberg). > > I would rather prefer to have something in the Generic Table "clients", > not > > coupled in any way with Iceberg. We can totally mimic the Iceberg logic > in > > Generic Table, but not "use" it. > > > > I will take a deeper look at the proposal. > > > > Regards > > JB > > > > On Fri, Feb 6, 2026 at 7:29 PM yun zou <[email protected]> > wrote: > > > > > Hi All, > > > > > > Generic Tables have been available since Polaris 1.0.0 and have seen > > > growing interest from an increasing number of customers. > > > > > > However, the current Generic Table capability has some limitations. One > > > key gap is the lack of credential vending support. Without credential > > > vending, query engines must access tables using long-lived, static > cloud > > > credentials configured directly in the engine runtime, which limits > both > > > usability and security. > > > > > > To address this, we propose adding credential vending support for > Generic > > > Tables. This enhancement would allow a Polaris catalog to dynamically > > vend > > > short-lived, scoped storage credentials to query engines at runtime > when > > > accessing Generic Tables. > > > > > > The goals of this proposal are to: > > > > > > 1. > > > > > > Enable credential vending support for Generic Tables in Polaris > > > 2. > > > > > > Deliver an end-to-end experience for currently supported table > > > formats, including Delta, Hudi, and Lance > > > 3. > > > > > > Maintain consistency with the existing Iceberg credential vending > > model > > > > > > Please find the attached short design document with additional details. > > We > > > would appreciate your review and valuable feedback. > > > > > > link to google doc: > > > > > > https://docs.google.com/document/d/1QzTx4tcS23_mF-gc77GbTqtwuRHY5f_Aa_6E4VSKFU4/edit?tab=t.0#heading=h.rpqtaz73xt4v > > > > > > Best Regards, > > > > > > Yun > > > > > >
