oqgraph-dev team mailing list archive

[Antony T Curtis <atcurtis@xxxxxxxxx>]

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
atcurtis@xxxxxxxxx



On Mar 4, 2013, at 3:05 PM, Arjen Lentz <arjen@xxxxxxxxxxxxx> 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
>