fix(plugin-postgresql): probe catalog presence so compatible engines without pg_matviews load (#1383)#1391
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
PostgreSQLCapabilitiesinfers 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 thepg_matviewscatalog. The version guard infetchTablestherefore passes, thepg_matviewsUNION 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 affectspg_foreign_tableandpg_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.
PostgreSQLPluginDriver.connect()override, mirroringCockroachPluginDriver): one portable query againstpg_catalog.pg_class/pg_namespacereturns which ofpg_matviews/pg_foreign_table/pg_sequencesthe server actually has. Result cached on the driver.pg_class/pg_namespaceare the lowest common denominator (an engine without them can't be used at all), so this avoids depending onto_regclass, which a minimal engine may also lack. Relation resolution is parse-time, so the probe and the catalog query must be separate statements.undefined_table(SQLSTATE42P01, matched by code not message), retry with the baseinformation_schema.tablesquery so a missing catalog can never abort the whole schema load.Changes
PostgreSQLCatalogPresence.swift(new): presence model + probe SQL + a pure parser frompg_classrelation names. Symlinked intoTableProTests/PluginTestSourcesfor 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 the42P01fallback infetchTables.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: thefetchTablesbuilder includes/omits thepg_matviewsandpg_foreign_tableunions per flag (and base-only contains noUNION ALL);PostgreSQLCatalogPresenceparses probe rows into the right flags.Docs
CHANGELOG (Fixed) and a Postgres-compatible-engines note in
docs/databases/postgresql.mdx.