fix(plugin-postgresql): resolve the oid of a type created after connect from the catalog - #2617
Merged
Merged
Conversation
…ct from the catalog instead of showing its columns as text Claude-Session: https://claude.ai/code/session_014THhVdsUjbCboxNLnQB1dR
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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.
Root cause
libpq reports each result column as a type oid, and the PostgreSQL plugin turned an oid into a type name from two tables: its built-in list of standard types, and an enum map read once at connect. A type created after that, in the same session or by any other client, had an oid in neither, so its columns came back as
unknownand rendered as text until the next reconnect. Found as a collateral item while working on #2484, which added a Create Type flow that runs into exactly this.Fix
ENUM(name)and an enum array asENUM[](name), the spellings the connect-time probe already used and the classifier reads; a domain reads as its base type so the cell edits as one; a composite, a range or a base type the built-in list lacks (money) keeps its own name. An oid the catalog does not know is remembered as unresolved so it is not asked about again, except when the lookup failed inside an aborted transaction, where it will succeed after the rollback.CREATE TYPEcommand tag therefore refreshes the enum map right after the statement, so aSELECTstreamed after aCREATE TYPEin the same tab reads the new enum on first sight.typelemon a variable-length type rather thantypcategory, which Redshift's catalog predates; measured against PostgreSQL 17, the two agree on every type but the pseudo-type_record.Evidence
A swiftc harness running the plugin's real sources against a throwaway PostgreSQL 17:
The one remaining
unknownis a type another client created, seen first through a streaming header; the next result on that connection reads it correctly.Tests
PostgreSQLCatalogTypeNamesTestscovers the spellings for every type kind, the lookup query shape, row parsing, negative caching and the enum probe parser. 17 cases pass with the column resolver suite.Changelog
Fixed: Columns of a PostgreSQL enum created during the session shown as text until the next reconnect.
https://claude.ai/code/session_014THhVdsUjbCboxNLnQB1dR