Skip to content

fix(postgres): bind the caller's schema in getTableColumns - #60

Merged
cursor[bot] merged 2 commits into
mainfrom
fix/pg-get-table-columns-schema
Aug 16, 2026
Merged

fix(postgres): bind the caller's schema in getTableColumns#60
cursor[bot] merged 2 commits into
mainfrom
fix/pg-get-table-columns-schema

Conversation

@geekypunk

Copy link
Copy Markdown
Contributor

getTablesAndViews() passes the schema each table was found in, but getTableColumns bound DEFAULT_SCHEMA ('public') and discarded the argument. Every table on a database whose objects live outside public came back with zero columns.

Measured against a real dbt warehouse (195 tables across 17 schemas, nothing in public):

marts.dim_person, schema bound to 'public' ->  0 columns
                                   'marts' -> 91 columns

The PK subquery also had no schema predicate at all. Postgres auto-names primary keys <table>_pkey, so two schemas holding a same-named table cross-match by construction — producing duplicated ColumnInfo rows and false-positive PK flags. This adds tc.table_schema = ku.table_schema and ku.table_schema = ?.

Both problems were latent while the provider only ever read public. #55 made them live: now that introspection walks every non-system schema, a staging/marts/public collision on orders or customers is the normal shape of a dbt warehouse, not the exception.

Verification

Deployed and measured on a live 195-table warehouse:

before after
schema snapshot 37 tables / 837 cols 195 / 4,070
tables returning zero columns 195 of 195 0 of 195
tables with correctly-detected PKs 67
tables with duplicated column rows 0
tables with every column flagged PK 0

A full brain re-init on that connection went from a 37-table snapshot to 195 tables / 4,070 columns, lifting table_classification 25 → 161 and inferred_table_relationship 17 → 280. The agent went from being blind to 14 of 18 schemas to correctly describing them.

Unit tests: PostgresIntrospectionProviderTest passes. A mocked ResultSet can't exercise SQL semantics, so the correctness evidence is the measurement above, against Postgres 18.

Relationship to #40

#40 is open and CONFLICTING. It fixed the same class of problem with a current_schema() approach that #55 superseded by scanning all non-system schemas. This PR sits on top of #55 instead and is independent of #40#40 can likely be closed once this lands.

getTablesAndViews() passes the schema each table was found in, but the method
bound DEFAULT_SCHEMA ('public'), so every table on a database whose objects live
outside public came back with zero columns. Measured on isha_data_clean:
marts.dim_person returns 91 columns when bound to 'marts', 0 when bound to
'public'.

The PK subquery also had no schema predicate at all. Postgres auto-names primary
keys '<table>_pkey', so two schemas holding a same-named table cross-match by
construction. Adds tc.table_schema = ku.table_schema and ku.table_schema = ?.

Local-only until PR #40 resolves its conflict with the multi-schema work in #55.
@geekypunk
geekypunk requested a review from a team as a code owner August 15, 2026 23:32
@venkateshsakamuri-lab

Copy link
Copy Markdown
Contributor

Looks good — approve.

@cursor
cursor Bot merged commit 8b47c67 into main Aug 16, 2026
9 checks passed
@cursor
cursor Bot deleted the fix/pg-get-table-columns-schema branch August 16, 2026 07:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants