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