Simon Riggs wrote:
> On Mon, 2006-11-20 at 16:30 -0500, Andrew Dunstan wrote:
>> I should add that it would have been nice if this discussion had
>> happened back in August when the work was being done.
>
> I'm happy to apologise. I hadn't made the connection at that point
> between the role of an enum datatype and the need to optimise FKs.
>
> Since MySQL has an enum type, it will aid portability to allow an enum
> type. However, I'm interested in providing a mechanism to speed up FKs
> without the *need* to adopt specific data domain specific datatypes.
>
No problem.
The original genesis of this work was an article I wrote for OReilly last
year, that looked at the taxonomy of enums. Essentially, the idea was to
get the advantages of enums done using lookup tables without the
disadvantages. Enumkit was a first step, but had the disadvantage of
needing compilationand having values hardcoded. Tom's work is essentially
to provide the same facility but with grammar and catalog support and
without requiring compilation.
Note that MySQL enum types are essentially anonymous types, and have a
number of very odd quirks. What Tom has submitted is, in my opinion, enums
done right, and orthogonally with the rest of the type system. IOW, a very
typical piece of Postgres development :-)
cheers
andrew