Skip to content

expression: Returning zero date instead of null for UPDATE out-of-range timestamp #61387

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

expression: Returning zero date instead of null for UPDATE out-of-range timestamp #61387

wants to merge 2 commits into from
+48 −0

Conversation

mjonss
Copy link
Contributor

@mjonss mjonss commented May 28, 2025

What problem does this PR solve?

Issue Number: close #61384

Problem Summary:

What changed and how does it work?

Check List

Tests

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below)
  • No need to test
    • I checked and no code files have been changed.

Side effects

  • Performance regression: Consumes more CPU
  • Performance regression: Consumes more Memory
  • Breaking backward compatibility

Documentation

  • Affects user behaviors
  • Contains syntax changes
  • Contains variable changes
  • Contains experimental features
  • Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

When updating a timestamp column to an out-of-range value, it is set to zero date, 0000-00-00 00:00:00 instead of NULL, to be the same as MySQL.

@ti-chi-bot ti-chi-bot bot added do-not-merge/needs-triage-completed release-note Denotes a PR that will be considered when it comes time to generate release notes. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels May 28, 2025
@tiprow tiprow
Copy link

tiprow bot commented May 28, 2025

Hi @mjonss. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@ti-chi-bot ti-chi-bot
Copy link

ti-chi-bot bot commented May 28, 2025

@mjonss: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
idc-jenkins-ci-tidb/mysql-test ac88a9a link true /test mysql-test
pull-integration-ddl-test ac88a9a link true /test pull-integration-ddl-test
idc-jenkins-ci-tidb/unit-test ac88a9a link true /test unit-test
idc-jenkins-ci-tidb/check_dev ac88a9a link true /test check-dev
idc-jenkins-ci-tidb/check_dev_2 ac88a9a link true /test check-dev2

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@ti-chi-bot ti-chi-bot
Copy link

ti-chi-bot bot commented May 28, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: winoros
Once this PR has been reviewed and has the lgtm label, please assign windtalker for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ti-chi-bot ti-chi-bot bot added the needs-1-more-lgtm Indicates a PR needs 1 more LGTM. label May 28, 2025
@ti-chi-bot ti-chi-bot
Copy link

ti-chi-bot bot commented May 28, 2025

[LGTM Timeline notifier]

Timeline:

  • 2025-05-28 16:40:49.947000304 +0000 UTC m=+37071.009017924: ☑️ agreed by winoros.

@mjonss mjonss added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 28, 2025
@mjonss
Copy link
Contributor Author

mjonss commented May 29, 2025

Hmm, I have a problem with solving this, since SELECT CAST('1111111111-' AS DATE) should return NULL, but UPDATE t SET ts_col = '1111111111-' should update to 0000-00-00, with different warnings in MySQL and the code path for UPDATE is using the same call graph from expression.BuildCastFunctionWithCheck->types.parseTime:
Screenshot 2025-05-29 at 01 20 48

Meaning whatever I return in evalTime when types.ParseTime() gives an error, will be the same for both the SELECT CAST and the UPDATE case.
I'm not sure it would even work by using the context, since UPDATE t SET ts_col = 'InvalidTimestamp' should give 0000-00-00 and UPDATE t SET ts_col = CAST('InvalidTimestamp' AS DATETIME) should give NULL...

@mjonss mjonss marked this pull request as draft May 29, 2025 00:48
@ti-chi-bot ti-chi-bot bot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels May 29, 2025
@mjonss mjonss requested a review from winoros May 29, 2025 01:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@winoros winoros Awaiting requested review from winoros

Assignees
No one assigned
Labels
do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. needs-1-more-lgtm Indicates a PR needs 1 more LGTM. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

UPDATE to incorrect timestamps results in NULL instead of '0000-00-00' or adjusted to next valid time, as in MySQL
2 participants
@mjonss @winoros