[Maria-developers] Deprecate INT(M) in SHOW?
Hello, We have an optional length for integer data types: TINYINT(N) SMALLINT(N) MEDIUMINT(N) INT(N) BIGINT(N) The number given in the parentheses imposes no any limits on the supported range. So for example BIGINT(1) is still a full-featured data type that can store and retrieve any 64-bit number (btw, I find this confusing). If I declare a column without N, it's later displayed in SHOW CREATE TABLE with the default length, so: CREATE TABLE t1 (a INT) becomes CREATE TABLE t1 (a INT(11)); The length is really important only in two cases: 1. In combination with ZEROFILL. 2. When the explicitly specified length is larger than the default length for the data type. For example, INT(40). In this case on cast to string, it's converted to VARCHAR(40) rather than to VARCHAR(11). In all other cases the length does not matter and has no any visible effects. Does anybody see any problems if in 10.4 we fix all metadata statements, such as: - SHOW CREATE TABLE t1 - DESCRIBE t1 - SELECT * FROM INFORMATION_SCHEMA.COLUMNS not to print the default length for non-ZEROFILL columns?
Am 23.04.2018 um 15:51 schrieb Alexander Barkov:
Does anybody see any problems if in 10.4 we fix all metadata statements, such as:
- SHOW CREATE TABLE t1 - DESCRIBE t1 - SELECT * FROM INFORMATION_SCHEMA.COLUMNS not to print the default length for non-ZEROFILL columns? yes - consumer code may rely on parse outputs
and frankly i assumed that when i define a unsigned tinyit(2) in can hold 0-99 and would reject -1 oder 100 in strict-mode with an error
https://dev.mysql.com/doc/refman/8.0/en/numeric-type-overview.html " *M* indicates the maximum display width for integer types. The maximum display width is 255. Display width is unrelated to the range of values a type can contain" I just inserted "1111111111" into an INT(5) column and was able to create a INT(200) column as well. On Mon, Apr 23, 2018 at 3:59 PM, Reindl Harald <h.reindl@thelounge.net> wrote:
Am 23.04.2018 um 15:51 schrieb Alexander Barkov:
Does anybody see any problems if in 10.4 we fix all metadata statements, such as:
- SHOW CREATE TABLE t1 - DESCRIBE t1 - SELECT * FROM INFORMATION_SCHEMA.COLUMNS not to print the default length for non-ZEROFILL columns? yes - consumer code may rely on parse outputs
and frankly i assumed that when i define a unsigned tinyit(2) in can hold 0-99 and would reject -1 oder 100 in strict-mode with an error
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Am 23.04.2018 um 16:17 schrieb Peter Laursen:
https://dev.mysql.com/doc/refman/8.0/en/numeric-type-overview.html " /|M|/ indicates the maximum display width for integer types. The maximum display width is 255. Display width is unrelated to the range of values a type can contain"
i know that - these days - but it's not logical and expected when you start to work with this stuff and one of many gotchas
I just inserted "1111111111" into an INT(5) column and was able to create a INT(200) column as well.
On Mon, Apr 23, 2018 at 3:59 PM, Reindl Harald <h.reindl@thelounge.net <mailto:h.reindl@thelounge.net>> wrote:
Am 23.04.2018 um 15:51 schrieb Alexander Barkov: > Does anybody see any problems if in 10.4 we fix all metadata statements, > such as: > > - SHOW CREATE TABLE t1 > - DESCRIBE t1 > - SELECT * FROM INFORMATION_SCHEMA.COLUMNS > not to print the default length for non-ZEROFILL columns? yes - consumer code may rely on parse outputs
and frankly i assumed that when i define a unsigned tinyit(2) in can hold 0-99 and would reject -1 oder 100 in strict-mode with an error
Le 23 avr. 2018 à 15:51, Alexander Barkov <bar@mariadb.com> a écrit :
Does anybody see any problems if in 10.4 we fix all metadata statements, such as:
- SHOW CREATE TABLE t1 - DESCRIBE t1 - SELECT * FROM INFORMATION_SCHEMA.COLUMNS not to print the default length for non-ZEROFILL columns?
Hi Alexander, The only issue I can see is for existing applications which try to parse the output of those statements and are expecting the length in their regex. So I'm not sure it's worth changing this output? Jocelyn
I would also disadvise diverging from MySQL here, as the is no particular reason as far as I can see. -- Peter On Mon, Apr 23, 2018 at 4:17 PM, jocelyn fournier < jocelyn.fournier@gmail.com> wrote:
Le 23 avr. 2018 à 15:51, Alexander Barkov <bar@mariadb.com> a écrit :
Does anybody see any problems if in 10.4 we fix all metadata statements, such as:
- SHOW CREATE TABLE t1 - DESCRIBE t1 - SELECT * FROM INFORMATION_SCHEMA.COLUMNS not to print the default length for non-ZEROFILL columns?
Hi Alexander,
The only issue I can see is for existing applications which try to parse the output of those statements and are expecting the length in their regex. So I'm not sure it's worth changing this output?
Jocelyn _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
participants (4)
-
Alexander Barkov -
jocelyn fournier -
Peter Laursen -
Reindl Harald