Si je le fais, CAST(1 AS SIGNED INTEGER)je finis toujours par obtenir un BIGINTretour, par exemple:
$ mysql -u root -p --column-type-info
Enter password:
--- Copyright and help message snipped for brevity ---
mysql> select cast(1 as signed integer);
Field 1: `cast(1 as signed integer)`
Catalog: `def`
Database: ``
Table: ``
Org_table: ``
Type: LONGLONG <== LONGLONG i.e. 64 bit integer
Collation: binary (63)
Length: 1
Max_length: 1
Decimals: 0
Flags: NOT_NULL BINARY NUM
+---------------------------+
| cast(1 as signed integer) |
+---------------------------+
| 1 |
+---------------------------+
1 row in set (0.00 sec)Je m'attendais à ce que le type de retour de cette distribution soit un LONG(entier 32 bits).
Si je sélectionne une colonne d'une table qui a un INTje vois que c'est en effet juste un LONG:
mysql> describe contact;
+------------+---------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------+------+-----+---------+----------------+
| contact_id | int(11) | NO | PRI | NULL | auto_increment |
== remainder of table snipped ==
mysql> select contact_id from contact where contact_id = 20;
Field 1: `contact_id`
Catalog: `def`
Database: `centreon`
Table: `contact`
Org_table: `contact`
Type: LONG <== LONG i.e. 32 bit integer
Collation: binary (63)
Length: 11
Max_length: 2
Decimals: 0
Flags: NOT_NULL PRI_KEY AUTO_INCREMENT NUM PART_KEY
+------------+
| contact_id |
+------------+
| 20 |
+------------+
1 row in set (0.00 sec)
mysql>Si je transforme la même colonne en un entier signé, je reçois à nouveau un entier 64 bits:
mysql> select CAST(contact_id as signed integer) from contact where contact_id = 20;
Field 1: `CAST(contact_id as signed integer)`
Catalog: `def`
Database: ``
Table: ``
Org_table: ``
Type: LONGLONG
Collation: binary (63)
Length: 11
Max_length: 2
Decimals: 0
Flags: NOT_NULL BINARY NUM
+------------------------------------+
| CAST(contact_id as signed integer) |
+------------------------------------+
| 20 |
+------------------------------------+
1 row in set (0.00 sec)Il y a un problème similaire signalé ici:
Mais malheureusement, le PO ne reçoit pas de réponse claire.
Est-ce un bug dans la CAST()fonction ou est-ce par conception?
En regardant les documents pour cast () / convert (), il ne mentionne que les entiers 64 bits dev.mysql.com/doc/refman/5.7/en/…
—
Philᵀᴹ
@Phil - Je l'ai lu encore et encore. Pourquoi dit-on
—
Kev
SIGNED [INTEGER]dans la section Le type du résultat peut être l' une des valeurs suivantes: . Un SIGNED INTEGERdans le contexte d'un CASTpas en fait un entier 32 bits?
Je lisais "MySQL prend en charge l'arithmétique avec des valeurs 64 bits signées et non signées. Si vous utilisez des opérateurs numériques (tels que + ou -) et que l'un des opérandes est un entier non signé, le résultat est non signé par défaut (voir la section 12.6.1, «Opérateurs arithmétiques»). Vous pouvez remplacer cela en utilisant l'opérateur de conversion SIGNED ou UNSIGNED pour convertir une valeur en un entier 64 bits signé ou non signé, respectivement. " part
—
Philᵀᴹ
@Phil - oui, je l'ai lu aussi, et en effet, cela se comporte comme prévu, c'est-à-dire faire des
—
Kev
SELECT 1+1résultats dans un BIGINT. Mais cela n'explique toujours pas pourquoi CAST()se comporte contrairement à la documentation (si je comprends bien) et produit un BIGINTmême si on lui demande de convertir en SIGNED INTEGERou UNSIGNED INTEGERsur une seule valeur scalaire.
La meilleure solution que j'ai trouvée ici: Convertir BIGINT UNSIGNED en INT