Jim C. Nasby wrote:
Andrew, you mentioned that if you want to change the ordering you should just create a new type. What about if you need to change the values that are in the enum? MySQL does (or at least did, it's been some time since I've messed with this) a horrible job at that. There's no way to rename anything; you have to add the new names you want, then do a bulk update, then delete the (now old) names. IMO this is broken.
It would just be a standard "ALTER TABLE foo ALTER COLUMN bar TYPE newtype USING expression" operation. You would write a function that took a value of the old type and returned a value of the new type and use a cll to that function in the expression. Since these would be named types, unlike the case in mysql where they are anonymously defined inline, this would present no difficulties at all.
Also, if we are going to maintain ordering and mapping (presumably via the internal number that we're storing), then I think we should expose that, at least optionally. So for example, you should be able to define what a specific enum value means. Not everyone will want a linear numbering starting at 0 afterall.
What on earth for? Users should not care in the slightest what the internal representation is . Users who want a map where the values are exposed should create a lookup table.
You keep saying that we are using the internal representation as the ordering. This is simply the wrong way to look at it. The internal representation REFLECTS the ordering; it doesn't impose it. The user has imposed the ordering when defining the type. In my enumkit I did provide a function that gave back the internal representation, but I am not by any means certain that that's a good idea.
cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
