feat(snowflake): add interactive table materialization support

[itsnamangoyal]

Problem

Snowflake's interactive tables (now GA) — optimized for low-latency, high-concurrency queries — had no dbt materialization.

Solution

This carries forward the great community contribution from @jimmyxie-figma in #1798, which added the original implementation. That PR stalled while awaiting review feedback, so we've picked it up and applied the requested fixes so it can land against main. Many thanks to @jimmyxie-figma for the original work! 🙏

Adds a materialized='interactive_table' materialization supporting static and dynamic (target_lag) variants. Since Snowflake has no ALTER INTERACTIVE TABLE, all rebuilds go through CREATE OR REPLACE:

• Static (cluster_by only): doesn't auto-refresh, and SHOW INTERACTIVE TABLES returns no query to diff — so it rebuilds via CREATE OR REPLACE on every run, like a normal table. A SQL change is reflected on the next run.
• Dynamic (target_lag + snowflake_warehouse): uses config-change detection on cluster_by / target_lag / snowflake_warehouse (matching dynamic_table). A SQL-only change is picked up with --full-refresh.

Interactive warehouse attachment

Adds a snowflake_interactive_warehouses config (a warehouse name or a list). After each run the table is attached to every listed interactive warehouse via ALTER WAREHOUSE <wh> ADD TABLES (<this>) — modeled on grants, so it runs every run and the config stays authoritative.

{{ config(
    materialized='interactive_table',
    cluster_by='id',
    snowflake_interactive_warehouses=['my_iw'],
) }}

Behavior & limitations

• Additive only. Attach runs every run (idempotent). Removing a warehouse from the list detaches it only on a static rebuild — CREATE OR REPLACE drops all attachments; a dynamic table that no-ops will not detach a de-listed warehouse. Full reconcile (detaching de-listed warehouses) is intentionally out of scope.
• No slot pre-check. Snowflake enforces the 10-table-per-warehouse cap and the MODIFY requirement; an over-cap or unauthorized attach surfaces the Snowflake error directly rather than a dbt-side pre-check.
• dbt does not create/alter/drop warehouses — it only attaches to pre-existing ones, and the run's role must hold MODIFY on each.

Review fixes applied on top of the original branch:

• Metadata is now read from SHOW INTERACTIVE TABLES (using the refresh_warehouse and target_lag columns).
• Surrounding parens are stripped from cluster_by values to avoid spurious rebuilds on unchanged tables.
• The introspected query field is now optional — SHOW INTERACTIVE TABLES returns a NULL query for static tables, which previously crashed the second run. Verified end-to-end against a live Snowflake account, with unit + functional regression tests added.

Resolves #1780.

[colin-k-rogers]

Took another pass after the rework — the static/dynamic split looks great. Static interactive tables now CREATE OR REPLACE every run like a plain table (with the SQL-change and rebuild-every-run functional tests to prove it), and change-detection is cleanly scoped to the dynamic target_lag variant. The is_interactive column defaulting + single-form unpacking in _parse_list_relations_result is also much nicer than the earlier flag-threaded version. 👍

Blocking:

Warehouse names are interpolated raw in the attach DDL.
In snowflake__attach_interactive_warehouses:

alter warehouse {{ warehouse }} add tables ({{ relation }})

{{ relation }} renders as a proper quoted identifier, but {{ warehouse }} is dropped in verbatim from config with no identifier handling. Any warehouse name that isn't a bare uppercase-safe identifier — mixed case, spaces, reserved words — produces broken or wrong-target DDL (e.g. my-wh or a case-sensitive name silently resolves to the wrong/nonexistent warehouse). Since this value drives an ALTER WAREHOUSE against a user-supplied name, it should go through proper identifier rendering (e.g. adapter.quote(...)) rather than raw interpolation.

One thing to confirm when you fix it: quoting changes Snowflake's case semantics (an unquoted foo resolves to FOO, but "foo" is case-sensitive), so decide whether the config value is meant to be a verbatim identifier or a quoted one, and make the rendering + docs consistent. The current raw form is the worst of both — it neither quotes nor documents a verbatim contract.

Non-blocking follow-ups:

1. cluster_by / snowflake_warehouse change-detection is format/case-sensitive (dynamic variant only).
parse_relation_results strips only a bare surrounding (...) and doesn't normalize case or a LINEAR(...) wrapper, and the warehouse comparison is raw string equality. If SHOW INTERACTIVE TABLES ever returns clustering keys uppercased or LINEAR(...)-wrapped, a dynamic table would spuriously rebuild every run. The dynamic no-op / multicol functional tests guard this, so it holds as long as those run in CI against a live account — the unit tests mock the SHOW output, so they won't catch a format surprise.

2. requires_full_refresh is dead code.
Since there's no ALTER INTERACTIVE TABLE, every change replaces, and the materialization only branches on configuration_changes is none — it never reads requires_full_refresh on the changeset or the three ...ConfigChange classes. Could drop it, or leave a one-line comment noting it exists only to satisfy the RelationConfigChange contract.

[itsnamangoyal]

@colin-rogers-dbt Thanks for the reviewing pass. Addressed all three:

Blocking — raw warehouse interpolation. Good catch. I went with a verbatim identifier contract rather than adapter.quote(), to stay consistent with snowflake_warehouse (which is interpolated verbatim in the create/replace DDL two lines away) and to preserve Snowflake's uppercase folding — quoting analytics_wh → "analytics_wh" would make it case-sensitive and break the common bare-name case. The macro now documents the contract explicitly, and the PR body / config docs spell it out: write the name as Snowflake expects, and wrap case-sensitive or special-character names in double quotes in the config string (e.g. '"my-wh"'). (cbb2114)

1 — format/case-sensitivity of change detection. Left the behavior as-is since it matches dynamic_table (same bare-paren strip, raw warehouse equality, no LINEAR(...)/case normalization), and added a comment at parse_relation_results recording exactly what you noted: the dynamic no-op / multicol functional tests are the guard against a live-account format surprise; the unit tests mock SHOW output so they won't catch one. (7a4e59b)

2 — dead requires_full_refresh. Dropped the changeset-level property (nothing reads it — no ALTER INTERACTIVE TABLE, so the materialization only branches on configuration_changes is none). Kept the three ...ConfigChange properties since they satisfy the abstract RelationConfigChange contract, with a one-line comment saying so. (ce80bbc)

[xuliangs]

My comments can be addressed in a separate PR. Thank you.

[itsnamangoyal]

(comment removed)

[hope-wat]

Did we pressure test the idempotent nature of dbt with how we are bringing in snowflake interactive tables? What is the intended --full-refresh behavior?

[itsnamangoyal]

Static interactive tables (cluster_by only):

• Always rebuilds via CREATE OR REPLACE every run. This is unavoidable because Snowflake returns NULL for query text in SHOW INTERACTIVE TABLES, so there's no way to diff and check if it changed..
• Fully idempotent — running twice produces identical results.
• SQL changes are reflected on the next run because we rebuild every time anyway.
• Warehouse attachment: CREATE OR REPLACE automatically drops the old table and detaches it from all warehouses. Then dbt re-attaches to every listed warehouse via ALTER WAREHOUSE ... ADD TABLES(), making the config authoritative each run.

Dynamic interactive tables (target_lag + warehouse):

• Config-change detection on cluster_by, target_lag, snowflake_warehouse.
• No rebuild if config unchanged → skip CREATE OR REPLACE, preserve auto-refresh window.
• Idempotent when config unchanged; safe when config changes (all changes trigger rebuild).
• Warehouse attachment runs similarly to static.

Test coverage: All testing performed against live Snowflake accounts (both unit/functional tests in the PR and separate live project validation).

--full-refresh Behavior

For dynamic tables: --full-refresh forces a rebuild regardless of config changes (bypasses the change-detection no-op). Intended behavior to keep it aligned with "normal" dynamic_table.

For static tables: --full-refresh has no additional effect since we are anyways rebuilding on every run.

[hope-wat]

I don't think this addresses what I am asking about because this response (some of it likely AI) is referring to dynamic tables. Dynamic tables and Interactive tables are fundamentally different -- dynamic is for real time data coming in while interactive is for low query latency.

[itsnamangoyal]

It is partially generated by AI. But interactive tables have 2 types: static and dynamic. Dynamic interactive table accepts target lag to keep the data up to date.