ddl: fix corrupted default value for bit type column

[tangenta]

What problem does this PR solve?

Issue Number: close #17641 close #17642

Problem Summary:

The ColumnInfo.OriginDefaultValue is corrupted when the column type is BIT. BIT type column values are stored as strings by JSON marshaling and read it by unmarshaling later. However, the data in a string can be changed in this case:

originBytes := []byte{25, 185}
originStr := string(originBytes)

mr, _ := json.Marshal(originStr)
var jsoned string
_ = json.Unmarshal(mr, &jsoned)

fmt.Printf("%v\n", []byte(originStr))
fmt.Printf("%v\n", []byte(jsoned))

[25 185]
[25 239 191 189]

If we store it as []byte, the problem disappeared. This is how DefaultValueBit works.

type ColumnInfo struct {
	// ...
	OriginDefaultValue    interface{} `json:"origin_default"`
	DefaultValue          interface{} `json:"default"`
	DefaultValueBit       []byte      `json:"default_bit"`
	// ...
}

The same problem exists in OriginDefaultValue. PR #12168 tried to restore the OriginDefaultValue from DefaultValueBit in the getter, but OriginDefaultValue is different from DefaultValue: OriginDefaultValue is used to skip the backfilling phase of AddColumn(). If a column's default value is modified by ALTER TABLE MODIFY COLUMN DEFAULT, they are not equal anymore(see the example in #17641).

What is changed and how it works?

This PR adds a field OriginDefaultValueBit to ColumnInfo, which borrows from DefaultValueBit to solve the problem completely.

Proposal: xxx

What's Changed:

• Getter and setter for OriginDefaultValue.
• A simple test case in Incorrect default value for bit type column #17641.

How it Works:
If the column type is BIT, set/get the content with OriginDefaultValueBit.

Related changes

• Need to cherry-pick to the release branch

Check List

Tests

• Unit test
• Integration test

Side effects

Release note

• fix corrupted default value for bit type column.

[wjhuang2016]

LGTM

[zimulala]

LGTM

[zimulala]

Do we need cherry-pick this PR to v4.0, v3.1, and v3.0?

[tangenta]

Do we need cherry-pick this PR to v4.0, v3.1, and v3.0?

Sure. Let's pick manually since there will be lots of conflicts(the parser also needs to be picked).

[codecov]

Codecov Report

Merging #18036 into master will increase coverage by 0.1610%.
The diff coverage is n/a.

@@               Coverage Diff                @@
##             master     #18036        +/-   ##
================================================
+ Coverage   79.3606%   79.5217%   +0.1610%     
================================================
  Files           546        546                
  Lines        150465     149710       -755     
================================================
- Hits         119410     119052       -358     
+ Misses        21524      21141       -383     
+ Partials       9531       9517        -14     

[djshow832]

LGTM

[djshow832]

/merge

[ti-srebot]

Your auto merge job has been accepted, waiting for:

• 18180

[ti-srebot]

/run-all-tests

[ti-srebot]

/run-all-tests

[zz-jason]

/merge

[ti-srebot]

Your auto merge job has been accepted, waiting for:

• 19675
• 19775
• 19455

[ti-srebot]

/run-all-tests

[AndreMouche]

LGTM

[ti-srebot]

@AndreMouche,Thanks for your review. The bot only counts LGTMs from Reviewers and higher roles, but you're still welcome to leave your comments.See the corresponding SIG page for more information. Related SIG: ddl(slack).

[ti-srebot]

@tangenta merge failed.

[ti-srebot]

@tangenta, please update your pull request.

[ti-srebot]

@tangenta, please update your pull request.

[zz-jason]

/merge

[ti-srebot]

Your auto merge job has been accepted, waiting for:

• 19535

[ti-srebot]

/run-all-tests

[ti-srebot]

cherry pick to release-3.0 in PR #20339

[ti-srebot]

cherry pick to release-4.0 in PR #20340