| Bug #31568 | Some "information_schema" entries suddenly report a NULL default | ||
|---|---|---|---|
| Submitted: | 12 Oct 2007 15:37 | Modified: | 30 Oct 2007 23:33 |
| Reporter: | Joerg Bruehe | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Information schema | Severity: | S3 (Non-critical) |
| Version: | 5.0.50 | OS: | Any |
| Assigned to: | Sergei Glukhov | CPU Architecture: | Any |
[16 Oct 2007 11:29]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/35638 ChangeSet@1.2536, 2007-10-16 16:25:05+05:00, gluh@mysql.com +3 -0 Bug#31568 Some "information_schema" entries suddenly report a NULL default updated result files
[17 Oct 2007 8:01]
Alexander Barkov
ok to push
[17 Oct 2007 8:28]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/35737 ChangeSet@1.2545, 2007-10-17 13:22:34+05:00, gluh@mysql.com +3 -0 Bug#31568 Some "information_schema" entries suddenly report a NULL default updated result files
[29 Oct 2007 8:42]
Bugs System
Pushed into 5.0.52
[29 Oct 2007 8:45]
Bugs System
Pushed into 5.1.23-beta
[29 Oct 2007 8:49]
Bugs System
Pushed into 6.0.4-alpha
[30 Oct 2007 23:33]
Paul DuBois
Test case change. No changelog entry needed.

Description: This was found in a custom build based on the 5.0.50 sources. Given the size of differences for these tests, I can *not* guarantee it did not happen in earlier versions, but I really think this one is new. When doing a "select * from columns;" ("funcs_1/r/innodb__datadict.result", line 1789 in the 5.0.50 version), several entries are reported to have a default of NULL which is not shown in the reference protocol (".result" file): COLUMNS COLUMN_TYPE ROUTINES SQL_MODE TRIGGERS ACTION_STATEMENT TRIGGERS SQL_MODE TRIGGERS DEFINER VIEWS VIEW_DEFINITION Similar differences are repeated later. The change is visible better at these places: @@ -11118,7 +11114,7 @@ SECURITY_TYPE varchar(7) NO CREATED datetime NO 0000-00-00 00:00:00 LAST_ALTERED datetime NO 0000-00-00 00:00:00 -SQL_MODE longtext NO +SQL_MODE longtext NO NULL ROUTINE_COMMENT varchar(64) NO DEFINER varchar(77) NO SHOW CREATE TABLE routines; @@ -12024,7 +12020,7 @@ TABLE_CATALOG varchar(4096) YES NULL TABLE_SCHEMA varchar(64) NO TABLE_NAME varchar(64) NO -VIEW_DEFINITION longtext NO +VIEW_DEFINITION longtext NO NULL CHECK_OPTION varchar(8) NO IS_UPDATABLE varchar(3) NO DEFINER varchar(77) NO @@ -12813,7 +12809,7 @@ EVENT_OBJECT_TABLE varchar(64) NO ACTION_ORDER bigint(4) NO 0 ACTION_CONDITION longtext YES NULL -ACTION_STATEMENT longtext NO +ACTION_STATEMENT longtext NO NULL ACTION_ORIENTATION varchar(9) NO ACTION_TIMING varchar(6) NO ACTION_REFERENCE_OLD_TABLE varchar(64) YES NULL @@ -12821,8 +12817,8 @@ ACTION_REFERENCE_OLD_ROW varchar(3) NO ACTION_REFERENCE_NEW_ROW varchar(3) NO CREATED datetime YES NULL -SQL_MODE longtext NO -DEFINER longtext NO +SQL_MODE longtext NO NULL +DEFINER longtext NO NULL SHOW CREATE TABLE triggers; Table Create Table TRIGGERS CREATE TEMPORARY TABLE `TRIGGERS` ( These differences show up in all 3 "datadict" tests run in this build: innodb__datadict memory__datadict myisam__datadict (As this was an "enterprise" configuration, the NDB test was not run.) How to repeat: Run the "funcs_1" suite. Suggested fix: Check whether the new default value is reported by intention or by accident; if the first: adapt the result file, if the latter: revert the code change. The "recent changes" (section C in the 5.0 manual) did not contain any mentioning (or I missed it).