[THEtheChad]

Fixes #458.

dbt's native unit tests create qualified temporary result tables, for example:

create or replace temporary table "DB"."S"."MY_MODEL__dbt_tmp" as (select 1 as x);
select * from "DB"."S"."MY_MODEL__dbt_tmp";

Creation failed with DuckDB's TEMPORARY table names can *only* use the "temp" catalog. Qualified reads, inserts and drops also failed after unqualified creation. DuckDB stores temporary tables in temp.main; Snowflake associates them with a database and schema, where they take precedence over permanent tables with the same name (docs).

The new per-connection TemporaryTables class owns qualification, schema validation and the existing OID registry extracted from TableStages. Both SQL resolution and table-stage resolution now use the same registry. It runs after unquoted identifiers are uppercased, validates the original schema before stripping CREATE qualifiers, and records ownership only after successful execution. Qualified table and column references matching a live temporary table are rewritten to temp.main. Permanent CREATE targets and non-table DDL targets are preserved.

Tests cover qualified creation, reads, INSERT, UPDATE, DELETE, MERGE, DROP IF EXISTS, replacement, permanent-table shadowing, aliases, CTEs, subqueries, joins, quoted mixed-case names, missing schemas, and a same-named sequence. A server test connects two sessions to one shared DuckDB instance and verifies that their same-named temporary tables remain isolated. The exact dbt sequence above was also run directly and returned [(1,)].

Remaining limitations:

• COPY INTO S.T targeting a temporary table still fails, as on main. COPY targets retain their Snowflake names for table-stage and load-history resolution.
• SHOW TABLES, DESCRIBE TABLE and information_schema.tables still omit temporary tables, as on main.
• DuckDB's single temporary namespace still allows an unqualified reference to find a temporary table after switching schemas, and prevents same-named temporary tables in different schemas of one session. Fixing those requires a separate naming strategy.
• Schema-qualified wildcards such as DB.S.T.* still hit DuckDB's parser limitation; T.* works. This also affects permanent tables on main.
• This change does not implement the separate case-resolution work in fix: resolve table, schema and database names with Snowflake's case rules #453.

Validation of the first two commits: 558 passed, 2 xfailed; ruff check, ruff format --check and pyright pass. The 25 focused cases pass here; against v0.12.1 / 3f65f02, 23 fail and two guards pass (other-schema resolution and sequence isolation).

Checked against a live Snowflake account (10.38): create or replace temporary table <db>.<schema>.qtemp as select 1 as x and a qualified select return (1,) there and here.

Follow-up: a schema's temporary tables go with it

Snowflake drops a schema's temporary tables with the schema, including other sessions' tables, on DROP SCHEMA, CREATE OR REPLACE SCHEMA and DROP DATABASE. Here they stayed in DuckDB's temp catalog, so their names stayed taken. A differential check against live Snowflake found this. The later commits fix it, along with what the fix turned up:

• The registry records each temporary table's owning schema by OID. Before each statement, a sweep drops temporary tables whose schema is gone or was replaced. The sweep is skipped inside an aborted transaction.
• CREATE TEMPORARY TABLE drops foreign key constraints, so a dropped schema can't be blocked by them. Snowflake doesn't enforce foreign keys either. Permanent tables' foreign keys are unchanged.
• CREATE TEMPORARY TABLE ... CLONE stays temporary, in the resolved schema.
• Owner resolution waits until after a DDL statement's implicit commit, and TemporaryTables.validate() keeps CREATE OR REPLACE from destroying a table when its target schema is missing.
• The catalog is read only when a statement names a live temporary table, so unrelated statements behave as on main.
• The cursor tracks BEGIN/COMMIT/ROLLBACK in either autocommit mode, and only once the statement succeeds. A failed BEGIN therefore can't leave a later INSERT committed when it should have rolled back.

Checked against live Snowflake: DROP SCHEMA, CREATE OR REPLACE SCHEMA and DROP DATABASE remove that schema's temporary tables from every session. BEGIN; DROP SCHEMA ...; ROLLBACK doesn't bring them back, because DDL commits.

Differences from Snowflake that remain:

• Snowflake validates a temporary table's foreign keys at CREATE: a missing table is 002003, and a non-key column is 001456. Here they aren't validated.
• With autocommit off, after a statement fails inside a transaction, DuckDB's transaction stays aborted. A statement that names a live temporary table with a database or schema qualifier then raises DuckDB's raw TransactionException, which the server returns as a 500. That belongs with fix: a statement that fails to compile no longer aborts the transaction #470, which turns the aborted state into a connector error.

Validation: 648 passed, 2 xfailed; ruff check, ruff format --check, pyright and typos pass.

🤖 Generated with Claude Code

[THEtheChad]

Merge order: this PR is easiest to land last. It overlaps three other open PRs:

• fix: resolve table, schema and database names with Snowflake's case rules #453 (and fix: resolve column names with Snowflake's case rules #454, which is stacked on it): fakesnow/conn.py and fakesnow/cursor.py
• fix: escape quoted stage, schema and database names in stage SQL #467: fakesnow/transforms/stage.py
• fix: a statement that fails to compile no longer aborts the transaction #470: fakesnow/cursor.py

Once those are in, I'll rebase this onto main.

The rebase onto #470 is more than a textual merge. #470 refuses every statement in a transaction that a failed statement aborted, until ROLLBACK. Six tests here create, replace or merge into a temporary table after a failed statement with autocommit off:

• test_temporary_table_create_after_failed_statement[unqualified|qualified]
• test_temporary_table_create_after_failed_statement_missing_schema
• test_temporary_table_replace_after_failed_statement_missing_schema[replace|if_not_exists]
• test_temporary_table_merge_after_failed_statement

After the rebase they'll expect #470's refusal, then run ROLLBACK, then make the checks they make now. In cursor.py, the result keeps #470's aborted-transaction check, and records BEGIN, COMMIT and ROLLBACK only once they succeed, as this PR does.

I've already done that merge, together with every other open PR of mine, in my fork's main: 1274 passed, 1 xfailed. The rebase will reuse it.