fix: PostgreSQL dialect can not support tinyint type#21445
Merged
Conversation
metegenez
reviewed
Apr 8, 2026
metegenez
left a comment
metegenez
left a comment
Contributor
There was a problem hiding this comment.
Thanks for the work. LGTM. Just adding 1 more test to clear the air would be great.
| ) | ||
| } | ||
|
|
||
| #[test] |
Contributor
There was a problem hiding this comment.
We can add a test that the default path still produces TINYINT, just for reference and degradation prevention.
metegenez
approved these changes
Apr 8, 2026
metegenez
left a comment
metegenez
left a comment
Contributor
There was a problem hiding this comment.
LGTM. If this does no break any upstream feature, we can merge it. Let's wait a bit for additional reviews.
Member
Author
|
@metegenez Hi, Do we still need to wait a while longer? |
Member
Author
|
@metegenez Thanks for your review! |
Rich-T-kid
pushed a commit
to Rich-T-kid/datafusion
that referenced
this pull request
Apr 21, 2026
## Which issue does this PR close? - No linked issue. ## Rationale for this change DataFusion's PostgreSQL unparser should emit PostgreSQL-compatible SQL for integer casts.`Int8` was still being rendered as `TINYINT`, which is not valid PostgreSQL syntax. This change makes PostgreSQL output `SMALLINT` instead. ## What changes are included in this PR? - Added an `int8_cast_dtype` hook to the SQL unparser dialect abstraction. - Updated `PostgreSqlDialect` to map `Int8` to `SMALLINT`. - Routed `DataType::Int8` unparsing through the dialect hook. - Added a regression test covering `select cast(3 as tinyint)]` with PostgreSQL unparser output. ## Are these changes tested? - Yes. Ran: - `cargo test -p datafusion-sql --test sql_integration cases::plan_to_sql::test_cast_to_tinyint -- --exact` - The test passes. ## Are there any user-facing changes? - Yes. PostgreSQL dialect SQL generation now renders `CAST(... AS SMALLINT)` for `Int8` values instead of `CAST(... AS TINYINT)`.
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
2 participants
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.
Which issue does this PR close?
Rationale for this change
DataFusion's PostgreSQL unparser should emit PostgreSQL-compatible SQL for integer casts.
Int8was still being rendered asTINYINT, which is not valid PostgreSQL syntax. This change makes PostgreSQL outputSMALLINTinstead.What changes are included in this PR?
int8_cast_dtypehook to the SQL unparser dialect abstraction.PostgreSqlDialectto mapInt8toSMALLINT.DataType::Int8unparsing through the dialect hook.select cast(3 as tinyint)]with PostgreSQL unparser output.Are these changes tested?
cargo test -p datafusion-sql --test sql_integration cases::plan_to_sql::test_cast_to_tinyint -- --exactAre there any user-facing changes?
CAST(... AS SMALLINT)forInt8values instead ofCAST(... AS TINYINT).