I'm brutally honest here:
I think we should really stay away from interpreting SQL or any other
kind of (view) definition in Polaris. There are tons of SQL dialects out
there, each requires its own fully implemented lexer/parser/interpreter
- plus views-in-views-in-views-in-views... constructs requiring
resolution of nested views. It eventually ends in implementing
yet-another-query-engine. I doubt that this is doable with a
"java.lang.String.replace(from, to)" approach.
Exposing authZ information via any kind of publicly accessible API to
every user sounds like an interesting source of information - especially
for the "not so good and nice guys".
Regarding the examples: what's the benefit over having the the ACLs on
the table/view defined in the intended way?
On 19.05.25 19:26, Prashant Singh 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
--
Robert Stupp
@snazy
