[eluser]tonanbarbarian[/eluser]
I have worked with a few different database engines over the yeah. MSAccess, Oracle and MYSQL to name a few. In my travels between the different databases I have come to the opinion that I only use standard SQL constructs where possible.
Chances are you might never want to run your code on anything but MySQL, but if you are building a CMS and you want to make it available to others you might want to consider making it database independant. Since CI can run on multiple database why not leverage that for your CMS.
So I do not use enum fields because they are not supported by all database engines.
And then the big issue here is what you are trying to do. You want to find the possible values in an Enum.
As someone with 10+ years in database design the first thing this suggests to me is that you should use a seperate table rather than an enum field.
Create a seperate table to store the values you had in the enum field and then replace the enum field with the id of the new table.
This is also how you should always design if you want to make your CMS database independant.
Or a final option, if the enum values will NEVER change, is to store the possible values in a config file something like this.
Code:
$config['enumX'] = array(
'A'=>'Apple',
'B'=>'Banana',
'C'=>'Cherry'
...
);
You can then just store the indexes (A,B,c) in the table and do the lookup manually. You need to consider this option carefully thought because it does not allow you to retrieve the values (Apple, Banana, Cherry) via a query. You will always have to convert all keys to values. There is nothing essentially wrong with that but it may become inconvenient at times.
But just to reinforce what said previously, this option only works if the values NEVER change, because you have to modify the code to change them.