On 10/27/05, Jim Nasby <jnasby@pervasive.com> wrote:
> Adding -hackers back to the list...
> > You could as equally say that it's ordering it by the order of the
> > enum declaration, which seems quite reasonable to me.
>
> I don't really see why that's considered reasonable, especially as a default. I could maybe see an argument for
havinga means to see this ordering, but IMO anything depending on that is broken. I don't think we should be making any
guaranteesabout how enums are stored in the database (including ordering).
> Your examples show why I don't think it's a good idea to use MySQL as a guide for how to do enums.
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.
> If we do decide to include the concept of ordering in enums, then it should be fully supported and not just an
artifactof 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.
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.