Heikki Linnakangas <heikki@enterprisedb.com> 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
> etc.
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
padding.
regards, tom lane