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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
