You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit cff1e73
Browse filesBrowse the repository at this point in the historyBrowse files
fix(postgres): introspect the session search_path, not a hardcoded 'public'
Every catalog query in PostgresIntrospectionProvider filtered on the literal
'public', and the Java side tagged every discovered object with a
DEFAULT_SCHEMA constant of the same value. Any database that keeps its tables
elsewhere was therefore completely invisible to DeepSQL.
The failure was silent and looked like success. On a dbt warehouse whose 37
tables live in `marts` and whose `public` holds nothing but extension views,
connection init ran all nine stages in 1.1 seconds and wrote
"All set! Brain is ready." at 100% — having produced an empty schema snapshot
("tables":[], totalTables 0), zero rag_documents, zero column profiles and zero
semantic models. Nothing errored, because nothing was found to process.
All 16 predicates now filter on current_schema(), and the schema tags come from
a resolveSchema(Connection) helper reading the same value, so the target schema
becomes a property of the connection — set it on the role, or with the JDBC
currentSchema parameter — instead of a compile-time constant. It falls back to
'public' when current_schema() cannot be read, so existing connections behave
exactly as before.
getDefaultSchema() deliberately keeps returning 'public'. Its four callers
(SchemaIntrospectionService, PgVectorSearchService, AzureSearchService,
TrainingService) use it to decide whether a name needs qualifying; returning
the session schema there would strip the qualifier off precisely the names that
need it, turning marts.dim_person into a bare dim_person.
Verified against a live 25GB warehouse: the same connection that previously
snapshotted 0 tables now snapshots 37 tables and 837 columns, and init proceeds
through real data sampling instead of completing instantly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"array_agg(a.attname ORDER BY array_position(ix.indkey, a.attnum)) as columns, " +
387
409
"ix.indisunique " +
388
410
"FROM pg_indexes i " +
389
-
"JOIN pg_class c ON c.relname = i.tablename AND c.relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = 'public') " +
390
-
"JOIN pg_index ix ON ix.indexrelid = (SELECT oid FROM pg_class WHERE relname = i.indexname AND relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = 'public')) " +
411
+
"JOIN pg_class c ON c.relname = i.tablename AND c.relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = current_schema()) " +
412
+
"JOIN pg_index ix ON ix.indexrelid = (SELECT oid FROM pg_class WHERE relname = i.indexname AND relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = current_schema())) " +
391
413
"JOIN pg_attribute a ON a.attrelid = c.oid AND a.attnum = ANY(ix.indkey) " +
392
-
"WHERE i.schemaname = 'public' " +
414
+
"WHERE i.schemaname = current_schema() " +
393
415
"GROUP BY i.tablename, i.indexname, i.indexdef, ix.indisunique " +
0 commit comments