MySQL Bugs: #26600: table PROFILING in INFORMATION SCHEMA has wrong data type

Bug #26600	table PROFILING in INFORMATION SCHEMA has wrong data type
Submitted:	23 Feb 2007 16:42	Modified:	11 Apr 2007 2:30
Reporter:	Giuseppe Maxia	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Information schema	Severity:	S3 (Non-critical)
Version:	5.0.35 (Community tree)	OS:	Linux (Linux, Mac OS X)
Assigned to:	Chad MILLER	CPU Architecture:	Any
Tags:	information_schema, show

Description:
Table Profiling in Information_schema has three fields of type VARCHAR(7). All these fields should hold floating point numbers, but they are stored as strings.

 tree: bk-internal.mysql.com:/home/bk/mysql-5.0-community

 ChangeSet@1.2387, 2007-02-22 16:25:47-05:00

How to repeat:
 select version();
+------------+
| version()  |
+------------+
| 5.0.35-log |
+------------+
1 row in set (0.00 sec)

desc information_schema.profiling;
+---------------------+-------------+------+-----+---------+-------+
| Field               | Type        | Null | Key | Default | Extra |
+---------------------+-------------+------+-----+---------+-------+
| Query_id            | bigint(20)  | NO   |     | 0       |       |
| Seq                 | bigint(20)  | NO   |     | 0       |       |
| State               | varchar(30) | NO   |     |         |       |
| Duration            | varchar(7)  | NO   |     |         |       | <-
| CPU_user            | varchar(7)  | YES  |     | NULL    |       | <-
| CPU_system          | varchar(7)  | YES  |     | NULL    |       | <-
| Context_voluntary   | bigint(20)  | YES  |     | NULL    |       |
| Context_involuntary | bigint(20)  | YES  |     | NULL    |       |
| Block_ops_in        | bigint(20)  | YES  |     | NULL    |       |
| Block_ops_out       | bigint(20)  | YES  |     | NULL    |       |
| Messages_sent       | bigint(20)  | YES  |     | NULL    |       |
| Messages_received   | bigint(20)  | YES  |     | NULL    |       |
| Page_faults_major   | bigint(20)  | YES  |     | NULL    |       |
| Page_faults_minor   | bigint(20)  | YES  |     | NULL    |       |
| Swaps               | bigint(20)  | YES  |     | NULL    |       |
| Source_function     | varchar(30) | YES  |     | NULL    |       |
| Source_file         | varchar(20) | YES  |     | NULL    |       |
| Source_line         | bigint(20)  | YES  |     | NULL    |       |
+---------------------+-------------+------+-----+---------+-------+
18 rows in set (0.01 sec)

Suggested fix:
Change the offending fields to DOUBLE

No information-schema table has every had a floating-point column before.  It has to be added, and it should be done in enterprise.

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/22952

ChangeSet@1.2415, 2007-03-26 14:21:30-04:00, cmiller@zippy.cornsilk.net +1 -0
  Bug#26600: table PROFILING in INFORMATION SCHEMA has wrong data type
  
  Bug#27047[partial]: INFORMATION_SCHEMA table cannot have BIGINT \
  	fields
  
  No Information_schema table has ever needed floating-point data 
  before.  Transforming all floating point to a string and back to a
  number causes a real data problem on Windows, where the libc may 
  pad the exponent with more leading zeroes than we expect and the
  significant digits are truncated away.
  
  This also makes interpreting an unimplemented type as a string into
  a fatal error in debug builds.  Thus, we will catch problems when we
  try to use those types in new I_S tables.

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/23028

ChangeSet@1.2415, 2007-03-27 11:30:53-04:00, cmiller@zippy.cornsilk.net +1 -0
  Bug#26600: table PROFILING in INFORMATION SCHEMA has wrong data type
  
  Bug#27047[partial]: INFORMATION_SCHEMA table cannot have BIGINT \
  	fields
  
  No Information_schema table has ever needed floating-point data 
  before.  Transforming all floating point to a string and back to a
  number causes a real data problem on Windows, where the libc may 
  pad the exponent with more leading zeroes than we expect and the
  significant digits are truncated away.
  
  This also makes interpreting an unimplemented type as a string into
  a fatal error in debug builds.  Thus, we will catch problems when we
  try to use those types in new I_S tables.

Pushed into 5.0.40

Pushed into 5.1.18-beta

No changelog entry needed because no I_S
table uses the new types yet.