Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
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.

Heikki's assertion is wrong in any case. The enumeration definition defines the ordering, and I can think of plenty of use cases where it does matter. We do not use an arbitrary ordering. An enum type is an *ordered* set of string labels. Without this the feature would be close to worthless. But if a particular application doesn't need them ordered, it need not use the comparison operators. Leaving aside the uses for GROUP BY and indexes, I would ask what the justification would be for leaving off comparison operators?

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.

This is a non-issue. The code sorts the oids before assigning them:

   /* allocate oids */
   oids = (Oid *) palloc(sizeof(Oid) * n);
   for(i = 0; i < n; i++)
       oids[i] = GetNewOid(pg_enum);
   /* wraparound is unlikely, but just to be safe...*/
   qsort(oids, n, sizeof(Oid), oid_cmp);

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


Globally unique is the design adopted, after much on-list discussion. That was a way of getting it *down* to 4 bytes. The problem is that the output routines need enough info from just the internal representation of the type value to do their work. The original suggestions was for 8 bytes - type oid + offset in value set. Having them globally unique lets us get down to 4.

As for efficiency, I agree with what Tom says about alignment and padding dissolving away any perceived advantage in most cases. If we ever get around to optimising record layout we could revisit it.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to