Hi!

David> Is there any chance of this changing in a future release? I mean, for a David> data type that can supposedly support 65535 different enumerated values, David> having a key space of only 65536 bytes seems inappropriate. So, I guess
I David> could have that many, only if each entry was one byte of text. That
seems David> pretty much useless to me.

This restriction is imposed because of the format in the MySQL .frm files. This restriction will be lifted in MySQL 4.0.

Note however that it will not be efficient to have more than a few 100 values in an ENUM. The reason is that when you store a row, the ENUM value is found by scanning a string of different values, which will be slow if there is many different values.

David> Is it possible to change this and recompile? Or is it likely to David> fundamentally break something? I would really like to use ENUMs for our
DB, David> but as they are currently implemented, they are pretty useless. I don't
see David> why there really needs to be a limit here, as I can implement the same David> functionality with look-up tables. It's just nice if I don't have to, by David> having it built into the system.

For your case, lookup tables is probably a better choice than using enums.

David> I wouldn't mind the DB getting a lot bigger by declaring, say, 1MB for David> string storage for each column. It's better than increasing it by a
factor David> of 16 to 32 times, by using 64 bytes of char instead of 2 bytes of enum
for David> each cell.

David> For now, I guess we will be implementing our own 'enum' types by using David> look-up tables for each column.

Regards, Monty