hqbhoho opened a new pull request, #12520: URL: https://github.com/apache/gravitino/pull/12520
### What changes were proposed in this pull request? Restore the types the engine assigned to the projected variables when returning the result of `applyProjection`, instead of forwarding the types the internal connector derived from its own column handles. ### Why are the changes needed? Gravitino and the internal connector can describe the same column with different Trino types. A MySQL tinytext column is an unbounded varchar in the metadata layer but a varchar(255) in the internal connector, so pushing a projection down produced an assignment whose two sides disagreed. Since Trino 444 the planner verifies the types in an assignment, which turns the disagreement into `Types don't match: varchar vs varchar(255)` while the query is still being planned. The normalization is type-agnostic: it does not special-case any column type, so it also covers `enum` / `set` and any future divergence. Assignments for columns the internal connector synthesized for pushed-down expressions have no counterpart among the engine variables and keep their internal types. A pre-existing, separate defect is deliberately not addressed here: `MySQLDataTypeTransformer` truncates the declared precision of MySQL time/datetime columns to 0 on every Trino version, so selecting such columns already fails at result serialization today, with or without pushdown. It will be reported and fixed separately. `applyAggregation` intentionally stays unchanged: its returned assignment names are synthesized by the internal connector and have no engine-side variables to restore types from; the JDBC base connector already types them with the engine-supplied aggregate output types. Fix: #12518 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? - Added `TestGravitinoMetadataApplyProjection` (5 cases, including a name-collision guard case): without the fix, the two restore cases fail with the mismatched types. - Added the `00015_projection_pushdown` tester to the jdbc-mysql test set: without the fix it reproduces the reported planner error (`Types don't match: varchar vs varchar(65535)`) on Trino 478; with the fix the whole jdbc-mysql test set passes (16/16). - Verified on Trino 443 (which has no assignment verification) that the change is a harmless normalization: the same queries return identical results. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
