Thomas Robitaille - 2009-12-19

Hi,

I am retrieving information about the datatypes in the results of a query
using the cursor.description. However, I need to be able to distinguish
between signed and unsigned integer types. For example, the following table:

+-------+----------------------+------+-----+---------+-------+

| Field | Type | Null | Key | Default | Extra |

+-------+----------------------+------+-----+---------+-------+

| a | tinyint(3) unsigned | YES | | NULL | |

| b | tinyint(4) | YES | | NULL | |

| c | smallint(5) unsigned | YES | | NULL | |

| d | smallint(6) | YES | | NULL | |

| e | int(10) unsigned | YES | | NULL | |

| f | int(11) | YES | | NULL | |

| g | bigint(20) unsigned | YES | | NULL | |

| h | bigint(20) | YES | | NULL | |

+-------+----------------------+------+-----+---------+-------+

Produces the following cursor description

(

('a', 1, 1, 3, 3, 0, 1),

('b', 1, 1, 4, 4, 0, 1),

('c', 2, 5, 5, 5, 0, 1),

('d', 2, 6, 6, 6, 0, 1),

('e', 3, 5, 10, 10, 0, 1),

('f', 3, 5, 11, 11, 0, 1),

('g', 8, 5, 20, 20, 0, 1),

('h', 8, 5, 20, 20, 0, 1)

)

The second element of each tuple, i.e. the 'type' is the same whether the
integer is signed or unsigned. Is this normal? If so, is using the fourth
column ('internal_size') a reliable and portable way to distinguish between
the two? (I wouldn't think so) And finally, it looks like at the moment, it
would especially not be possible to distinguish signed from unsigned 64-bit
integers.

Would it be possible/easy to add new type codes for unsigned integer types?

Thanks for any help,

Thomas