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
I have searched the existing issues, and I could not find an existing issue for this bug
Current Behavior
The macro that backs object-level persist_docs uses {{ relation.type }} to derive the object type in the COMMENT ON statement. This breaks for materialized_view materializations:
15:35:01 Database Error in model funds_movement (models/marts/funds_movement.sql)
15:35:01 Expected one of TABLE or VIEW or COLUMN or MATERIALIZED or SOURCE or SINK or INDEX or FUNCTION or CONNECTION or TYPE or SECRET or ROLE or DATABASE or SCHEMA or CLUSTER, found identifier "materialized_view"
15:35:01 LINE 5: comment on materialized_view "marta"."public"."funds_moveme...15:35:01 ^15:35:01 compiled Code at target/run/mz_get_started/models/marts/funds_movement.sql15:35:0115:35:01 Done. PASS=3 WARN=0 ERROR=2 SKIP=0 TOTAL=5
Expected Behavior
The persist_docs config should work for materialized_view materializations.
Steps To Reproduce
Attempt to use the persist_docs config with a materialized view model.
Relevant log output
No response
Environment
No response
Additional Context
We've fixed this a while back for dbt-materialize (which shims dbt-postgres) in Materialize #21878, but it really should be fixed at the source! This issue was also reported by a user of the dbt-risingwave adapter (dbt-risingwave #31), which also shims dbt-postgres.
The text was updated successfully, but these errors were encountered:
Is this a new bug?
Current Behavior
The macro that backs object-level
persist_docs
uses{{ relation.type }}
to derive the object type in theCOMMENT ON
statement. This breaks formaterialized_view
materializations:Expected Behavior
The
persist_docs
config should work formaterialized_view
materializations.Steps To Reproduce
Attempt to use the
persist_docs
config with a materialized view model.Relevant log output
No response
Environment
No response
Additional Context
We've fixed this a while back for
dbt-materialize
(which shimsdbt-postgres
) in Materialize #21878, but it really should be fixed at the source! This issue was also reported by a user of thedbt-risingwave
adapter (dbt-risingwave
#31), which also shimsdbt-postgres
.The text was updated successfully, but these errors were encountered: