(I had a private bet with myself that Tom Lane would object to the "bit
shaving" ;-) )
Tom Lane wrote:
>> Ok, I'll run one more idea up the flagpole before giving up on a 4 byte
>> on disk representation. :) How about assigning a unique 4 byte id to
>> each enum value, and storing that on disk. This would be unique across
>> the database, not per enum type. The structure of pg_enum would be a bit
>> different, as the per-type enum id would be gone, and there would be
>> multiple rows for each enum type. The columns would be: the type oid,
>> the associated unique id and the textual representation.
> That seems not a bad idea. I had been considering complaining that the
> array-based catalog structure was denormalized, but refrained ... I like
> the fact that this approach makes it normalized.
> Another thought is that this isn't really tied to any particular width
> of stored enum values. You could easily imagine a compile time switch
> to say you want 2-byte enums instead of 4. Or 8; or even 1.
> Even more radical: do it at runtime. You could assign the typlen
> (stored width) of an enum type at creation time on the basis of the
> largest identifier it contains. This might be a bit too weird because
> enums created earlier would have a size advantage over those created
> later, but if you are looking to shave space ...
I'm not sure I like either of these options. The configure option at
least would make it too easy to break loading a dump from a db with
different compile time limit, and the runtime typelen stuff just seems
I'm inclined to say let's keep it simple and stay with a fixed 4-byte
> That reminds me: were you intending to allow an ALTER ENUM operation
> to add (or remove, or rename) elements of an enum type? The above
> method would fail for the case where an ADD operation needed to assign
> an identifier wider than the type allowed for.
No, I think that's something of a footgun. We'd have to check every row
to ensure we weren't orphaning some value.
The workaround is to create a new enum type and then do "alter table
alter column type ..." although I realise that could cause dependency
Of course, people will be able to hack the catalog if they want to, but
then it will be on their heads if things break - the intention is to
treat these as essentially static - for dynamic stuff use a domain or a
In response to
pgsql-hackers by date
|Next:||From: Chris Browne||Date: 2006-08-16 18:23:51|
|Subject: Re: BugTracker|
|Previous:||From: Tom Lane||Date: 2006-08-16 17:33:18|
|Subject: Re: Enum proposal / design |