Hi Prashant
Thanks for the proposal.
I understand the purpose (about FGAC which is something we plan to
work on), but I'm not sure if it's a good approach with this kind of
SQL functions.
Polaris, as a catalog, should:
1. not do query engine work, but more interact with any query engines
(same discussion we had about TMS)
2. not be opinionated on SQL dialect
I agree that Polaris would need to do "enforcement" but supporting any
query engines/SQL dialect is very difficult. I think we should explore
"abstraction" like Substrait or Coral to be agnostic.
I think Polaris should "integrate" query engines, with a clear
boundary between what's query engine and catalog responsibility.
I think the proposal has great value, but I'm not yet convinced by the
impl approach.
Regards
JB
On Mon, May 19, 2025 at 7:26 PM Prashant Singh
<prashant.si...@snowflake.com.invalid> wrote:
>
> Hi everyone,
>
> I’d like to propose adding *context-aware functions* to Apache Polaris so
> that view definitions can resolve security context on the Polaris side (aka
> catalog end without depending on engines).
>
> *Proposed functions*
>
> 1.
>
> *is_principal('<principal_name>')* – returns TRUE if the authenticated
> principal matches <principal_name>, otherwise FALSE.
> 2.
>
> *is_principal_role('<principal_role_name>')* – returns TRUE when
> <principal_role_name> appears in the principal’s role set.
> 3.
>
> *is_catalog_role('<catalog_role_name>')* – analogous check at the
> catalog-role level.
>
> *Why it matters*
>
> These predicates make views dynamic. Example:
>
> CREATE VIEW dynamic_vw ASSELECT *FROM ns1.layer1_tableWHERE
> is_principal_role('ANALYST');
>
> When a user whose one of principal roles include *ANALYST* calls LOAD
> VIEW, Polaris rewrites the view to
>
>
> -
>
> SELECT * FROM ns1.layer1_table WHERE TRUE;
>
>
> For everyone else the view becomes
>
> -
>
> SELECT * FROM ns1.layer1_table WHERE FALSE;
>
>
> The result is better and consistent control of the identity resolution
> without relying on the engine side changes and giving polaris more
> authority in enforcing things like FGAC (WIP by me).
> Note the same can be extrapolated to any Polaris stored entity.
>
> *Proof of concept*
>
> I’ve put together a quick POC branch:
> https://github.com/apache/polaris/compare/main...singhpk234:polaris:dyanmic/view
>
> *Prior art*
>
> Snowflake context functions :
> https://docs.snowflake.com/en/sql-reference/functions-context
> <https://docs.snowflake.com/en/sql-reference/functions-context>
> Databricks Unity Catalog offers a similar mechanism called *dynamic views*:
> https://docs.databricks.com/aws/en/views/dynamic
>
> *Next steps*
>
> If the community is interested, we can discuss API surface, engine
> implications, and a roadmap for merging.
>
> Eager to hear your feedback!
>
> Best,
> Prashant Singh
