Chris Travers wrote:
>>
> How hard would it be to automatically create enum_ tables in the back
> ground to emulate MySQL's enum type? Sort of like we do with SERIAL
> datatypes... Part of the problem is that MySQL's enum type is so
> braindead from a database design perspective that most of us would not
> be interested in using it. Emulating an int foreign key for another
> created table might make it ok, though.
>
The thing that occurs to me is that if you really want the enum type in
PostgreSQL (assuming that there exists a real need), a PostgreSQL person
would create their own type. Or, if not, just create a wrapper function
that handles the input/output display and call it explicitly.
So to me, the need seems very weak. However, if your goal is
compatibility, I guess we need it. The problem is it's very difficult to
do in a general way. We'd probably have to do it specifically for enum,
and have it generate the types automatically on the fly. Someone would
have to do some interesting things with the parser, too. Right now even
the varchar() type, for instance, is kind of a hack.
Ultimately to do it in a general way I think we'd need functions that
return a type that can be used in a table definition. Aside from the
many problems I don't know about, there are two other problems:
(1) After the table (or column?) is dropped, we need to drop the type.
(2) Functions currently don't support variable numbers of arguments, so
enum still wouldn't be simple. We could do something kinda dumb-looking
like:
CREATE TABLE mytable (
color ENUM("red,green,blue,orange,purple,yellow");
);
And have the hypothetical ENUM function then parse the single argument
and return a type that could be used by that table.
Is this achievable with a reasonable amount of effort? Is this
function-returning-a-type a reasonable behavior?
If nothing else it would clean up the clutter of varchar() and the like,
that currently use the hacked-in catalog entry "atttypmod" or something
like that.
Regards,
Jeff Davis
