@bobbyiliev Unsure how we actually deploy an update to our dbt adapter!

Also I decided to go with the approach of allowing an options override instead of accepting a oidc_auth_enabled boolean as a connection option. This is because:

1. This oidc_auth_enabled option doesn't exist for cloud
2. Future flexibility if we need to specify a connection option

@bobbyiliev Unsure how we actually deploy an update to our dbt adapter!

@SangJunBak This gets auto released after bumping the version bump (version.py + setup.py). What we usually do is to split the version bump itself out into a follow-up release PR. We usually merge the feature + CHANGELOG entry first, then do a separate PR to cut the release to PyPI.

Would you mind reverting the verions bump and adding a changelog entry here? Then we can have a follow-up PR for the release itself. That way if there are other pending changes they all get released together.

3. Ran

cd misc/dbt-materialize
uv venv dbt-venv
uv pip install --python dbt-venv/bin/python pip
dbt-venv/bin/pip install .
dbt-venv/bin/dbt debug --profiles-dir .

Did you by any chance test this with a full dbt run / dbt build, not just dbt debug? The verification shows the options making it into the connection string, but I'd feel better knowing a real query round-trip works with an override that actually changes behavior (e.g. setting auto_route_catalog_queries: off). Happy to try this on my end if you hit any blockers setting this all up!

Did you by any chance test this with a full dbt run / dbt build, not just dbt debug? The verification shows the options making it into the connection string, but I'd feel better knowing a real query round-trip works with an override that actually changes behavior (e.g. setting auto_route_catalog_queries: off). Happy to try this on my end if you hit any blockers setting this all up!

I think the verification also tries to connect, so the way I actually tested it was toggling welcome_message to on and off and seeing the output! I can write a unit test for this however!

Created an integration test in the latest commit. Can test via bin/mzcompose --find dbt-materialize run default -k test_options_override

Followup PR to bump the versions #36213

@claude review

Claude finished @bobbyiliev's task in 1m 32s —— View job

Code Review

• Gather context
• Read changed files
• Compose final review

Overall this is a clean, well-scoped implementation. A few issues worth addressing before merge:

connections.py — options string escaping (potential bug)

misc/dbt-materialize/dbt/adapters/materialize/connections.py:141

kwargs["options"] = " ".join([f"--{k}={v}" for k, v in options_parts])

Values containing spaces will produce a malformed options string. For example, options: {application_name: "my app"} would emit --application_name=my app, which psycopg2 passes directly to the server and would be parsed incorrectly (the token after the space would be treated as a separate, unrecognized option).

The PostgreSQL wire protocol expects values with spaces to be quoted: --application_name='my app'. Consider adding quoting for values that contain spaces or special characters:

def _format_option(k, v):
    # Quote values containing spaces
    if ' ' in str(v):
        return f"--{k}='{v}'"
    return f"--{k}={v}"
kwargs["options"] = " ".join([_format_option(k, v) for k, v in options_parts])

Fix this →

connections.py — search_path can appear twice if also in credentials.options

misc/dbt-materialize/dbt/adapters/materialize/connections.py:137-139

search_path = credentials.search_path
if search_path is not None and search_path != "":
    options_parts.append(("search_path", search_path))

If a user also specifies search_path in their options: dict (e.g. to override the dbt-managed value), it will appear in options_parts twice — once from the options merge, and once from this block. The second one wins since psycopg2 uses the last occurrence, so the behavior is correct, but it's redundant. Consider skipping the append if search_path is already in options_dict:

if search_path is not None and search_path != "" and "search_path" not in options_dict:
    options_parts.append(("search_path", search_path))

connections.py — upstream divergence comment could be stronger

misc/dbt-materialize/dbt/adapters/materialize/connections.py:102-104

The comment pins to v1.17.3 which is good. One minor improvement: including a direct link to the upstream source file (not just a line anchor) would make it easier to diff in the future. That said, the existing comment is already better than most.

connections.py — application_name can be set both ways

The application_name is passed as a first-class kwarg at line 129, but a user could also put it in credentials.options. These are both sent to psycopg2, but via different mechanisms — psycopg2 keyword arg vs. the options string. The kwargs value takes precedence, meaning a user cannot override application_name via options: even though they might expect to. This is a minor UX inconsistency; not a bug.

test_connection_options.py — looks good

The integration test is well-designed: it flips both options to their non-default values and queries current_setting() to confirm they were applied server-side. This directly validates the options_dict.update(credentials.options) merge. The scope="class" fixture level is appropriate.

One suggestion: the test file currently has no schema key in dbt_profile_target. Check whether the base class fixture provides a default, or whether this should be explicit. If tests fail intermittently due to a missing schema, this could be the cause.

profile_template.yml — no type annotation for options

The new options field at line 44 has no type: annotation. For dbt init, this means it'll be prompted as a plain string, which would be confusing for a dict-valued field. The field is optional (no default:), so it may just be skipped by dbt init in practice — but it's worth verifying or adding type: dict if supported.

CHANGELOG.md — clean

Entry under Unreleased is correct and the version bump has been removed per the review discussion.

Summary: The core logic is correct and the approach (copying open() and adding the merge before passing options to psycopg2) is a reasonable trade-off given the upstream API limitations. The main thing worth fixing before merge is the options string value escaping for values with spaces.

Regarding claude's output, so I did notice that spaces had no negative effect in the connection. I.e. setting the cluster to "weewoo quickstart" would still work, even with other arguments. This might be a postgres specific thing that Materialize already handles?