> How are clients supposed to know the meaning of credential properties in the "config" section?
How are clients supposed to know the meaning of *any* properties written to a generic table? That clients need to interpret the payload of a generic table response is already intrinsic to the generic table design. True, adding credential vending pushes generic table support towards the service being slightly more opinionated about the generic table metadata (i.e. the location is now implied to be a place that may require credentials to access) but as this would be an opt-in for your generic tables I don't see this as a blocking issue. --EM On Fri, Feb 6, 2026 at 10:57 AM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Yun, > > The proposal looks reasonable to me in general after a quick review of the > doc. > > I have one concern, though, which may be a whole can of worms, I'm afraid > :) > > How are clients supposed to know the meaning of credential properties in > the "config" section? The doc proposes to define it as a generic property > bag. > > The example appears to use properties that Iceberg (java?) clients might > use in a similar situation. However, the Generic Tables API is not related > to Iceberg in any way (AFAIK). > > Plus, I do not think these properties are well-defined even in Iceberg > specifications. > > WDYT? > > Thanks, > Dmitri. > > On Fri, Feb 6, 2026 at 1: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 > > >
