Skip to content

[FLINK] Support flink timestamp types#54

Open
zhanglistar wants to merge 1 commit into
gluten-0530from
codex/support-flink-timestamp-types
Open

[FLINK] Support flink timestamp types#54
zhanglistar wants to merge 1 commit into
gluten-0530from
codex/support-flink-timestamp-types

Conversation

@zhanglistar

Copy link
Copy Markdown
Member

No description provided.

@zhanglistar zhanglistar changed the title Support flink timestamp types [FLINK] Support flink timestamp types Jun 24, 2026
@zhanglistar

Copy link
Copy Markdown
Member Author

Timestamp with zone already implemented under prestosql, try reuse this.

@lgbo-ustc

Copy link
Copy Markdown
image fix the code format and license header check

lgbo-ustc

This comment was marked as duplicate.

@lgbo-ustc lgbo-ustc left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the change. One concern before merging: the new Flink timestamp types are not consistently wired into the string/type parsing paths. FlinkTimestampType::toString() returns TIMESTAMP(p) / TIMESTAMP_LTZ(p), but the current type parser only supports numeric parameters for DECIMAL(p, s); WORD(...) is parsed as a child type list, so parseType(type->toString()) will not round-trip for these new types. Also, getType() registers FLINK_TIMESTAMP / FLINK_TIMESTAMP_LTZ, while the public string representation exposes TIMESTAMP / TIMESTAMP_LTZ, which makes the external type names inconsistent.

Could you please either add parser/getType support for the string forms emitted by toString(), or change toString() to emit a registered/parseable representation? It would also be good to add tests for parseType(FLINK_TIMESTAMP(3)->toString()), parseType(FLINK_TIMESTAMP_LTZ(9)->toString()), getType(...), and invalid precision bounds.

code review by codex

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants