On 10/27/05, Jim Nasby <[EMAIL PROTECTED]> 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 having a means to see this ordering, but > IMO anything depending on that is broken. I don't think we should be making > any guarantees about 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 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. 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. ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
