Skip to content

fix(plugin-postgresql): probe catalog presence so compatible engines without pg_matviews load (#1383)#1391

Merged
datlechin merged 3 commits into
mainfrom
fix/1383-pg-matviews
May 22, 2026
Merged

fix(plugin-postgresql): probe catalog presence so compatible engines without pg_matviews load (#1383)#1391
datlechin merged 3 commits into
mainfrom
fix/1383-pg-matviews

Conversation

@datlechin
Copy link
Copy Markdown
Member

Fixes #1383.

Problem

Connecting to a PostgreSQL wire-compatible engine (the reporter used db9.ai) fails with ERROR: relation "pg_matviews" does not exist, and tables don't load.

Root cause

PostgreSQLCapabilities infers catalog presence purely from the server version: hasMaterializedViewsCatalog { serverVersion >= 90_300 }. Compatible engines report a real-looking Postgres version (>= 9.3) but don't implement the pg_matviews catalog. The version guard in fetchTables therefore passes, the pg_matviews UNION runs, and because it sits in the same compound query as the base tables/views, the whole query fails and schema loading breaks. The same version-only assumption affects pg_foreign_table and pg_sequences. A server version reflects the dialect target, not which system catalogs are actually implemented (CockroachDB and Redshift have hit this same class of bug).

Approach

Stop inferring catalog existence from the version. Probe it.

  • Connect-time probe (PostgreSQLPluginDriver.connect() override, mirroring CockroachPluginDriver): one portable query against pg_catalog.pg_class/pg_namespace returns which of pg_matviews / pg_foreign_table / pg_sequences the server actually has. Result cached on the driver. pg_class/pg_namespace are the lowest common denominator (an engine without them can't be used at all), so this avoids depending on to_regclass, which a minimal engine may also lack. Relation resolution is parse-time, so the probe and the catalog query must be separate statements.
  • Gate on probed presence, fall back to version when the probe didn't run.
  • Safety net: if the table query still hits undefined_table (SQLSTATE 42P01, matched by code not message), retry with the base information_schema.tables query so a missing catalog can never abort the whole schema load.

Changes

  • PostgreSQLCatalogPresence.swift (new): presence model + probe SQL + a pure parser from pg_class relation names. Symlinked into TableProTests/PluginTestSources for tests.
  • PostgreSQLSchemaQueries.swift: fetchTables(schemaLiteral:includeMaterializedViews:includeForeignTables:) query builder (pure, testable; lives with the other schema queries).
  • PostgreSQLPluginDriver.swift: connect() override + catalog probe + presence-gated unions and sequences, plus the 42P01 fallback in fetchTables.

No PluginKit ABI change (internal driver logic). PostgreSQL is a bundled plugin, so it ships with the next app release; no registry update.

Tests

PostgreSQLCatalogCompatibilityTests: the fetchTables builder includes/omits the pg_matviews and pg_foreign_table unions per flag (and base-only contains no UNION ALL); PostgreSQLCatalogPresence parses probe rows into the right flags.

Docs

CHANGELOG (Fixed) and a Postgres-compatible-engines note in docs/databases/postgresql.mdx.

@datlechin datlechin merged commit c31db9b into main May 22, 2026
1 check passed
@datlechin datlechin deleted the fix/1383-pg-matviews branch May 22, 2026 16:17
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.

ERROR: relation "pg_matviews"does not exist

1 participant