Skip site navigation (1) Skip section navigation (2)

Re: Enum proposal / design

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Dunstan <pgsql(at)tomd(dot)cc>
Subject: Re: Enum proposal / design
Date: 2006-08-16 17:55:25
Message-ID: 44E35C0D.8010204@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
(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 
messy.

I'm inclined to say let's keep it simple and stay with a fixed 4-byte 
global size.

> 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 
problems too.

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 
lookup table.

cheers

andrew

In response to

Responses

pgsql-hackers by date

Next:From: Chris BrowneDate: 2006-08-16 18:23:51
Subject: Re: BugTracker
Previous:From: Tom LaneDate: 2006-08-16 17:33:18
Subject: Re: Enum proposal / design

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group