Andrew Dunstan <[EMAIL PROTECTED]> writes: > Well, for one thing, I have no plan to allow explicit setting of the internal > representational value, as one can do in C. And the fact that it's an int > underneath is in implementation detail, IMNSHO. After all, KL just advised > using a text domain with a check constraint for enums, so int storage is > hardly a fundamental part of enum-ness.
Well it is in that there's not much point to them if it's not. That is, you can _already_ use a text domain with check constraints if you want. The only point to enums is to let you get the syntax niceness that provides without burdening the implementation with any costs. That is, the whole point of enums is to let you have your cake and eat it to. You get to give the programmers a nice safe interface but tell your DBA you're storing the most space efficient storage format possible. If you don't get that then you may as well use integers or text strings as you prefer. > Maybe this all just reflects my background in languages that are more strongly > typed than C and have first class enums. I suspect this is a matter of perspective. If you speak to the programmers they're liable to agree with you that these languages give this abstract enum thing that could just as easily be stored as strings. But if you speak to the language designers they'll tell you that the whole point was to package up an integer-backed storage in an abstract way and if you implemented them as text there wouldn't have been any point in having them in the language. Even languages like lisp treat symbols as integers internally. The whole point of having symbols is to give an abstraction that programmers can use to hide the internally grungy details that allow reasonably efficient implementations. symbols in lisp can be stored and compared efficiently because they're interned and can be treated as integers. If they were stored as strings there would be no point in having them. -- greg ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org