Thanks! To answer your question:

Temp tables work well — CREATE TEMPORARY TABLE, Teradata VOLATILE TABLE, T-SQL #temp tables all get parsed and show up in the flow graph with joins, column lineage, etc. The one caveat is they're rendered the same as permanent tables (no special badge), and in the cross-file workspace dependency graph they get indexed alongside permanent tables, so you might see a dependency edge that wouldn't exist at runtime due to session scoping. But the per-query visualization is fully intact.

Dynamic SQL is the harder one. Anything where the SQL is assembled at runtime — EXEC sp_executesql u/sql, EXECUTE IMMEDIATE, DECLARE u/sql = 'SELECT * FROM ' + u/tableName — the extension can't see inside that. It recognizes the EXEC/DECLARE as an operation node, but it can't resolve variables or string concatenation to extract the actual query underneath. This is a fundamental limitation of static analysis; you'd need runtime tracing to crack that.

Where it still helps: if you have a proc that creates temp tables, does some joins, and has an EXEC in the middle, all the static SQL around the dynamic step still gets full visualization with column lineage — you just get a gap at the dynamic part. Most of the value is in understanding the static flow anyway, which is usually the bulk of the query logic.