-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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.
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
executor: change the evaluation order of columns in Update
and Insert
statements (#57123)
#58494
base: release-7.5
Are you sure you want to change the base?
executor: change the evaluation order of columns in Update
and Insert
statements (#57123)
#58494
Conversation
Signed-off-by: ti-chi-bot <[email protected]>
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release-7.5 #58494 +/- ##
================================================
Coverage ? 72.1404%
================================================
Files ? 1417
Lines ? 413456
Branches ? 0
================================================
Hits ? 298269
Misses ? 95169
Partials ? 20018
Flags with carried forward coverage won't be shown. Click here to find out more.
|
This is an automated cherry-pick of #57123
What problem does this PR solve?
Issue Number: ref #56829
Problem Summary:
In the previous logic, when we use
UPDATE
orINSERT ON DUPLICATE
, the new row will be generated in the following order:UPDATE
andINSERT
, they are evaluated incomposeGeneratedColumns
anddoDupRowUpdate
respectively.However, auto-generated columns may rely on the on-update-now columns to generate value. For example in #56829 (comment)
expired_at
is generated based on the latest timestamp value fromupdated_at
. So we will get wrongexpired_at
value. Even worse,expired_at
is the part of the indexidx_c_on_expired_at
. So querying dataexpired_at
using index scan and full table scan will get different result, since in full table scan,expired_at
is calculated in real-time.This also explains #56829 (comment) why changing
VIRTUAL
toSTORED
will not yield such error, although this value itself is incorrect.What changed and how does it work?
To address this problem, this PR refactor the logic of
INSERT ON DUPLICATE
andUPDATE
. More specifically:updateRecord
.updateRecord
.errorHandler
function forUPDATE
andINSERT
to handle error/warning inupdateRecord
.Check List
Tests
Side effects
Documentation
Release note
Please refer to Release Notes Language Style Guide to write a quality release note.