Hi guys About FGAC, I think we have to be more pragmatic.
We can identify three parts in FGAC: - column masking - column filtering - row filtering I believe the easiest to start with is column masking. Let's start with column masking. The cinematic would be: 1. The query engine calls the catalog getTable() with credentials 2. The catalog calls the authorizer to verify credentials and to get the associated roles 3. The catalog returns a "mask function name" to the query engine (basically an id). This function name should be part of the Iceberg REST getTable response (it's not today, so maybe we should start a discussion with the Iceberg community to add this optional "mask" field. 4. Then the query engine "maps" the "mask name" to its logic. It means that: 1. The query engine is "coupled" with Polaris "mask name": it should "translate" the mask name to its internal function. If the "mask name" is not understood by the query engine, a "permission exception" happens. 2. With this approach, we don't need an abstract representation in Polaris (no Substrait, no Coral, ...). Polaris just "stores" mask names. 3. It's a PoC approach that would allow us to evaluate the "plumbing" required between catalog/authorizer/query engine. Thoughts ? I propose to start drafting a document with step by step FGAC patterns. Regards JB On Tue, May 20, 2025 at 10:05 AM Prashant Singh <prashant.si...@snowflake.com.invalid> wrote: > > > Let's work together on a proper design. > > For sure ! will be reaching out soon for this ! > > Best, > Prashant Singh
