Tom Dunstan wrote:
Here is an updated version of the enums patch. It has been brought up to date and applies against current CVS HEAD. The original email is at [1], and describes the implementation.
I'm sorry I missed the original discussions, but I have to ask: Why do we want enums in core? The only potential advantage I can see over using a look-up table and FK references is performance. And I'd rather spend time improving the performance of FK checks than add extra machinery to do the same thing in a different way.
Ignoring my general dislike of enums, I have a few issues with the patch as it is:
1. What's the point of having comparison operators for enums? For most use cases, there's no natural ordering of enum values.
2. The comparison routine compares oids, right? If the oids wrap around when the enum values are created, the ordering isn't what the user expects.
3. 4 bytes per value is wasteful if you're storing simple status codes etc. Especially if you're doing this for performance, let's do no harm by wasting space. One byte seems enough for the typical use cases. I'd even argue that having a high upper limit on the number of enum values encourages misuse of the feature.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
