fix: resolve operator ambiguity in i3 foreign key check#72
Closed
fix: resolve operator ambiguity in i3 foreign key check#72
Conversation
Add explicit int2[] cast to key_cols parameter to resolve "operator is not unique" error when using the @> operator with pg_catalog schema qualification. Fixes #62
Add test coverage for i3_non_indexed_fks.sql query to catch potential operator ambiguity issues. The test: - Installs intarray extension which can cause operator ambiguity - Creates parent and child tables with foreign keys - Verifies i3 query executes without errors - Checks that foreign keys without indexes are detected Also update all psql commands in CI to use PAGER=cat per PostgresAI command execution rules to ensure non-interactive behavior. Related to #62
Temporarily remove the ::int2[] cast on key_cols parameter to verify that the new CI test correctly catches the operator ambiguity error. This commit is expected to fail CI tests. Related to #62
NikolayS
commented
Sep 30, 2025
| # Create extensions (pg_stat_statements may not work without shared_preload_libraries) | ||
| psql -h localhost -U postgres -d test -c 'CREATE EXTENSION IF NOT EXISTS pg_stat_statements;' || echo "Warning: pg_stat_statements extension not available" | ||
| psql -h localhost -U postgres -d test -c 'CREATE EXTENSION IF NOT EXISTS pgstattuple;' | ||
| psql -h localhost -U postgres -d test -c 'CREATE EXTENSION IF NOT EXISTS intarray;' |
Add explicit `::int2[]` cast to `key_cols` parameter in the i3 foreign key check query. This resolves "operator is not unique" errors that can occur in certain PostgreSQL environments (such as Google CloudSQL). The error occurs when PostgreSQL cannot determine which @> operator to use between smallint[] operands. By explicitly casting both sides to int2[], we eliminate any ambiguity. While standard PostgreSQL installations (including those with intarray extension) may not exhibit this error, the explicit cast is a best practice that ensures consistent behavior across all environments. Fixes #62
Owner
Author
|
Superseded by #81 — rebased onto current master (the original branch would have silently dropped c1 from the menu). SQL fix is identical; CI improvements carried over. |
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
Fixes the "operator is not unique" error in the i3 (foreign keys with missing or bad indexes) check by adding explicit type casting to the
key_colsparameter.Problem
Users reported encountering this error when running the i3 check:
This occurred on line 66 of
i3_non_indexed_fks.sqlwhere the@>operator was being used withoperator(pg_catalog.@>)syntax to avoid conflicts with the intarray extension (fixed in PR #35), but PostgreSQL still couldn't resolve which operator to use due to type ambiguity.Solution
Added explicit
::int2[]cast to thekey_colsparameter to match the left side of the comparison, ensuring PostgreSQL knows exactly which@>operator to use:Both sides are now explicitly
int2[](smallint array), eliminating the ambiguity.Fixes #62