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 https://github.com/dbt-athena/dbt-athena/issues/613 and https://github.com/dbt-athena/dbt-athena/pull/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 https://github.com/dbt-athena/dbt-athena/pull/659#issuecomment-2131148532, 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.createcall here https://github.com/dbt-athena/dbt-athena/blob/v1.8.1/dbt/include/athena/macros/materializations/models/table/table.sql#L30.