Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> 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.
If you would like to be able to index enum columns, or even GROUP BY one,
you need those; whether the ordering is arbitrary or not is irrelevant.
> 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.
This is a fair point --- it'd be better if the ordering were not
dependent on chance OID assignments. Not sure what we are willing
to pay to have that though.
> 3. 4 bytes per value is wasteful if you're storing simple status codes
I've forgotten exactly which design Tom is proposing to implement here,
but at least one of the contenders involved storing an OID that would be
unique across all enum types. 1 byte is certainly not enough for that
and even 2 bytes would be pretty marginal. I'm unconvinced by arguments
about 2 bytes being so much better than 4 anyway --- in the majority of
real table layouts, the hoped-for savings would disappear into alignment
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?