Add snowflake_table resource for creating and managing table objects about terraform-provider-snowflake

[iserko]

I've got a use-case.
We Terraform the following resources:

• AWS S3 bucket
• AWS Firehose Delivery stream to the S3 bucket
• Snowflake Stage for the prefix in the S3 bucket
• Snowflake Pipe that COPY's from the stage into the table

Right now I have to manually create the table before I can Terraform anything, but would be neater to have the provider be able to do it.

[nelg]

I've got a use-case.
We Terraform the following resources:

* AWS S3 bucket

* AWS Firehose Delivery stream to the S3 bucket

* Snowflake Stage for the prefix in the S3 bucket

* Snowflake Pipe that COPY's from the stage into the table

Right now I have to manually create the table before I can Terraform anything, but would be neater to have the provider be able to do it.

Same problem here

[elliottohara]

My use case is just about the same as above. Really need this.

[doctoryes]

@djzempsnowflake We've left TABLE (and VIEW) objects unmanaged so far in edX's Snowflake implementation, as they're relatively dynamic and changing. We manage DATABASE and SCHEMA using Terraform, along with USER, ROLE, permissions-granting, etc.

[davehowell]

@djzempsnowflake
The snowflake_table_grant resource has recently had an on_future property added so you can use it to grant on all future tables in a schema. That's enough to manage permissions.

My tables are created by various other processes, ELT tools, transformation tools like DBT and by analyst users. I have basic Roles that those tools use to make permissions straight forward.

Not possible to pre-define all the tables. There are a few I know up-front, e.g. some metadata tables that ETL tools use, but then I think creating those is the responsibility of those tools, so I don't see any use for a table resource.

[sjauld]

I tend to agree that managing tables in terraform is not a great idea for most use cases.

However it would still be good for the provider to support tables. I think the goal of any terraform provider should be to fully wrap the underlying API (or in this case, wrap the API wrapped in a SQL driver).

So, on balance, +1 for this issue. I'll probably need it in about 12 months so if someone builds it before then that will make future me happy.

[davehowell]

@sjauld what's the use-case out of curiosity?

[khoatrandata]

I haven't seen mentioned in the docs whether the table will be dropped when schema change or not?