Closed bdewilde closed 4 months ago
@bdewilde Thanks for the report!
I can confirm that this change likely caused the regression, because adding that ;
back does seem to restore the previous behavior.
Following the reproduction case:
create materialized view if not exists "jerco"."dbt_jcohen"."int_test" as
SELECT 1 AS foo, 2 AS bar;
create index if not exists
"13008d29068d3f93577844cc147dd809"
on "jerco"."dbt_jcohen"."int_test" using btree
(foo);create index if not exists
"d9594d6bdc8ad05fa90f86119dd485f3"
on "jerco"."dbt_jcohen"."int_test" using btree
(bar);
I don't know if adding it back in exactly the same spot is right way to resolve this, versus somewhere else in the MV creation/update flow. Either way, we should:
Note we have no tests for verifying this behavior one way or another in existence currently. The multiple index thing should cover this ;
case.
Re-opening for backports
Is this a new bug in dbt-core?
Current Behavior
Hi! Upon updating to dbt v1.7.14, all models materialized as "materialized_view" and including more than one index in its config fail with a syntax error. This did not happen in v1.7.13. The error looks like this:
It looks like the multiple "create index" statements are being concatenated together incorrectly. I'm wondering if this is related.
Expected Behavior
I would expect materialized views with multiple configured indexes to build and run without error.
Steps To Reproduce
Model (
int_test.sql
):Command:
dbt run --select int_test
Output:Removing one or both of those indexes works just fine:
=>
Relevant log output
No response
Environment
Which database adapter are you using with dbt?
postgres
Additional Context
No response