You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By defining a custom target temp_schema as config arg of the model, user will be able to isolate where tmp tables used for table materialization are being created. This will allow better access controle on those transient state tables.
Describe alternatives you've considered
No response
Who will this benefit?
User that materialize tables and desire to controle where temporary tables are going to be created. This schema control will allow to limit exposure of transient state tables to consumers.
Is this your first time submitting a feature request?
Describe the feature
Following dbt-labs/dbt-athena#613 and dbt-labs/dbt-athena#659. I would like to extend this feature to any tmp table used during table materialization operations.
By defining a custom target temp_schema as config arg of the model, user will be able to isolate where tmp tables used for table materialization are being created. This will allow better access controle on those transient state tables.
Describe alternatives you've considered
No response
Who will this benefit?
User that materialize tables and desire to controle where temporary tables are going to be created. This schema control will allow to limit exposure of transient state tables to consumers.
Are you interested in contributing this feature?
Yes
Anything else?
According to dbt-labs/dbt-athena#659 (comment), 3 main use cases need to be cover.
I believe this can be achieve by passing a temp_schema argument from the model configuration then to the
api.Relation.create
call here https://github.com/dbt-athena/dbt-athena/blob/v1.8.1/dbt/include/athena/macros/materializations/models/table/table.sql#L30.The text was updated successfully, but these errors were encountered: