An option (perhaps) is to consider a patch which I applied to a mysql branch some 13 years ago which never was accepted into mysql at the time:
The patch was the following: Inside unireg.cc, the function rea_create_table() had an added call to the handler before calling mysql_create_frm() ... the practical upshot was that the handler (storage engine) could fixup fields. This was desirable so that we could write statements like: CREATE TABLE OrderLine () TYPE=pfx; The pfx engine would populate the content with all the fields/indexes as required. *Shrug* But I digress. I still don't understand what is so wrong with using ENUM. Antony T Curtis atcur...@gmail.com On Mar 4, 2013, at 3:05 PM, Arjen Lentz <ar...@openquery.com> wrote: > Hi Antony, ANdrew > >> Ahh yeah. if you change the type, you must fix the index key decode. > > You reckon you can do that, Andrew? > > How are you for time, Antony? Couple of curious things open that are your > turf... if we're to make the 10 freeze deadline, we can really use your help > in the next few weeks! > > > Btw Andrew, in terms of backward compatibility... I don't think we should > keep accepting INT for latch in the create table as its probably unworkable > to allow both with other code requirements (such as the index foo), but > accepting the old numerical references in latch in queries should be ok. Then > a user can update the schema but if need be keep using their app code > unchanged. > > > Cheers, > Arjen. > -- > Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) > Australian peace of mind for your MySQL/MariaDB infrastructure. > > Follow us at http://openquery.com/blog/ & http://twitter.com/openquery > -- Mailing list: https://launchpad.net/~oqgraph-dev Post to : oqgraph-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~oqgraph-dev More help : https://help.launchpad.net/ListHelp
