Re: enums

Gregory Maxwell wrote:

>Yes, MySQL is broken in some regards, as usual. However, the API isn't
>bad (except for the fact that it doesn't care what invalid crap you
>throw at it), and more importantly there are thousands of apps and
>developers who think around that interface. We should copy it without
>the brokenness as much as possible unless we have good cause
>otherwise.
>
>

mmm ... no. It is too broken. We should do enums orthogonally with other
type definitions in PostgreSQL. Where I would like to get to is that we
have a flavor of CREATE TYPE that will create the enum type for us,
including all the support that I build into my little kit. And if you
want to change the enumeration set on a column, you would use ALTER
TABLE foo ALTER COLUMN bar TYPE newtype USING ...

Inline declarations of enums does not strike me as good.

>
>
>>If we do decide to include the concept of ordering in enums, then it should be fully supported and not just an artifact of our storage mechanism. This means supporting things like being able to re-order the accepted values in an enum. But like I said, I just don't see the use case for doing that.
>>
>>
>
>So what do you propose we do for a default ordering? I hope you don't
>think we should force a sort as though the enum labels were text...
>That almost certainly incorrect for most applications of enums, which
>are used to make opaque labels more human compatible.
>
>

Yeah, lexical ordering is surely wrong. I believe that the enumeration
order is the only correct ordering. If you wanted lexical ordering, you
could always do "order by myenum::text".

>MySQL's behavior of allowing the user to specify the collation in the
>typedef makes a lot of sense to me, it doesn't matter that it actually
>works as an artifact of the storage backend. I'd argue that it would
>make sense to sort by the specification order even if we changed the
>backend to use varchars rather than numbers.
>
>
>

Can't see the point in it, I must confess.

cheers

andrew