Support for account-level parameters

[LouisAmon]

Is your feature request related to a problem? Please describe.

Kind of, as it interferes with how some previous resources have been implemented : for example the network_policy_attachment is actually an ALTER ACCOUNT statement

Describe the solution you'd like

There are many parameters in Snowflake, and they can be set at the account-level to provide company-wide defaults and policies.

(NB: some parameters can only be set at the account level)

Typically, it would be nice to be able to set the SAML_IDENTITY_PROVIDER account parameter (it's just an example)

Maybe the best way to do it would be to create an Account resource (which has to be imported into the state via terraform import) then set attributes that perform the ALTER ACCOUNT statement ?

Additional context

https://docs.snowflake.com/en/sql-reference/sql/alter-account.html

https://docs.snowflake.com/en/sql-reference/parameters.html

[menathan]

Is there any other way people are currently automating this using some sort of workaround still using the same provider?

[danieladams456]

A snowflake_account_parameter resource type could be good for setting things like the date related parameters. It would only set a specific parameter, so wouldn't have the chance of wiping out other parameters it shouldn't be setting.

[dlouseiro]

In the meantime I noticed that the snowflake_account_parameter is already supported, but it only allows one to set account level parameters, not session parameters or object parameters at the account level, for example.

So, if I want to set the timezone parameter or data retention time at the account level I'm not allowed to do so using the snowflake_account_parameter, the snowflake_session_parameter or snowflake_object_parameter.

So, it would be nice to either add a set_for_account boolean to the snowflake_session_parameter/snowflake_object_parameter or allow these parameters to be manipulated as snowflake_account_parameter resources.

[sfc-gh-asawicki]

We are closing this issue as part of a cleanup described in announcement. If you believe that the issue is still valid in v0.89.0, please open a new ticket.