ROW ACCESS POLICY ASSOCIATION

[systematics78]

there is exists resources to create views, tables, row access policy, but there is no resources to associate policy with views or tables

[nosterlu]

same as this issue?

[fr33z3]

I'm sorry but are there any plans to implement that?

[sfc-gh-asawicki]

Hey @fr33z3. Yes, we will be doing that as part of https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#supporting-all-snowflake-ga-features. We don't have a timeline yet, but we will share it as soon as we have it.

[fr33z3]

@sfc-gh-asawicki that is awesome. Thank you. I'm just curious if there are any workarounds currently?

[sfc-gh-asawicki]

Currently, the workaround for almost every use case is https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/unsafe_execute. This is a dangerous resource, though, so please make sure you check its limitations before using.

[systematics78]

https://registry.terraform.io/providers/aidanmelen/snowsql/latest/docs/resources/exec

You can use the snowsql_exec resource to execute queries.

resource "snowsql_exec" "sf_metadata_utility_apply_row_access_policy" { name = "APPLY_ROW_ACCESS_POLICY_" depends_on = [ some resorces ]

create {
    statements = <<-EOT
    ALTER VIEW db.schma.view
    ADD
    ROW ACCESS POLICY db.schne.row_access
    ON (WAREHOUSE_NAME);
    EOT

}

delete {
    statements = <<-EOT
   ALTER VIEW db.schma.view
    DROPP
    ROW ACCESS POLICY db.schne.row_access
    ON (WAREHOUSE_NAME);
    EOT

} }

[fr33z3]

@sfc-gh-asawicki thank you unsafe_execute solved my issue at the moment. @systematics78 thank you. I saw that provider but didn't really want to introduce another provider so I decided to go with unsafe_execute resource from snowflake provider.

[systematics78]

name "unsafe_execute" confusing - :)

Deprecation Experimental resource. Will be deleted in the upcoming versions. Use at your own risk.

at the end snowflake admins executing the queries, scripts and so on, so on that case Snowflake should deprecate the DDL statements? From my opinion such kind of resources should not be depreciated. snowflake releasing many features which is not supported by current version of provider, updating provider also not easy process for some organizations.

[sfc-gh-asawicki]

@systematics78 it's confusing for good reasons :) It was added to the provider to solve precisely the case you mentioned, but we want people to use it sparingly, hence the wall of warnings.

We have had many discussions regarding this resource, and we will keep a "safer" version of it inside the provider. I can't give you any timeline now, but I can guarantee that we will not remove the unsafe resource without a suitable alternative.

[sfc-gh-jmichalak]

Hi @systematics78 @nosterlu @fr33z3 👋 Associating row access policies should be managed in the associated resources (views, tables, etc.) configs. Recently, we've reworked views which support this, and we will rework tables in the future.

For managing policies themselves, there is row_access_policy resource, which is currently being reworked.