fix: fall back to proisagg/proiswindow on PostgreSQL < 11 in get_routines (#88) - #110
Merged
Merged
Conversation
…ines (#88) get_routines hardcoded the PG 11+ query that references pg_proc.prokind unconditionally. prokind was introduced in PostgreSQL 11, replacing the boolean columns proisagg/proiswindow; on 9.x/10, referencing it fails at parse time (SQLSTATE 42703, "column \"prokind\" does not exist"). The builtin driver queries current_setting('server_version_num') first and branches on >= 110000; this repo's version had no such check. Ported the version branch exactly, extracting the query-selection logic into a pure routine_query_for_version(server_version_num) function so it's unit-testable without a live server. TDD: added metadata_tests.rs (4 tests covering both branches and the exact 110000 boundary). Confirmed the new pre-PG11 tests fail against a simulated pre-fix implementation (the old hardcoded modern-only query) before restoring the real fix. Verified live against a real PostgreSQL 10.21 instance (podman postgres:10): confirmed "prokind" genuinely does not exist on that server (reproducing the exact SQLSTATE 42703 error from the issue), then confirmed the pre-fix binary fails with that identical error against the real PG10 server while the post-fix binary succeeds -- correctly listing a real function as FUNCTION and correctly EXCLUDING a real aggregate (via the legacy proisagg filter), which is the one part of this fix impossible to verify without an actual pre-PG11 server. Also verified the modern branch still works unchanged against the existing PG16 live-test database.
aesslinger
added
the
prerelease:rc
Version suggestionBased on this PR's title (
This is informational only — no tag or release is created automatically yet. |
1 similar comment
Version suggestionBased on this PR's title (
This is informational only — no tag or release is created automatically yet. |
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
1 participant
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.
Summary
get_routineshardcoded the PG 11+ query referencingpg_proc.prokindunconditionally.prokindwas introduced in PostgreSQL 11, replacing the boolean columnsproisagg/proiswindow; on 9.x/10, referencing it fails at parse time (SQLSTATE 42703,column "prokind" does not exist).current_setting('server_version_num')first and branches on>= 110000; ported that exactly, extracting the query-selection logic into a pureroutine_query_for_version(server_version_num)function so it's unit-testable without a live server.Fixes #88.
Test plan
metadata_tests.rs(4 tests covering both branches and the exact110000boundary). Confirmed the pre-PG11 tests fail against a simulated pre-fix implementation (the old hardcoded modern-only query) before restoring the real fix.cargo test --lib— 325 passedcargo clippy --all-targets -- -D warnings— cleancargo fmt --all -- --check— cleanpodman postgres:10), not just simulated:prokindgenuinely does not exist on that server — reproduced the exactSQLSTATE 42703error from the issue via rawpsqlFUNCTIONand correctly excluding a real aggregate (via the legacyproisaggfilter) — the one part of this fix that's impossible to verify without an actual pre-PG11 server, since a mock/unit test can't reproduce PostgreSQL's own catalog behavior