Re: Enum proposal / design - Mailing list pgsql-hackers

Andrew Dunstan wrote:

>> 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 thought the runtime one was kinda cute, actually, but you would have 
to have duplicate functions for the differently sized types, eg. 
enum1_out, enum2_out etc since otherwise you wouldn't know what sized 
parameter you were just handed. And as Tom pointed out there could be 
issues when someone wanted to modify the type.

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

Fair enough. I'm ok with 4 bytes; 8 seemed a bit gratuitous.

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

Well, one option that we might want to consider down the line is doing 
all that behind the scenes in an ALTER TYPE statement. Of the 
unsupported stuff that I listed, being able to alter the enum definition 
was the one that I thought had the most likely use case.

Anyway, it's not something that we need to sort out straight away since 
there's a workaround. I suspect that it only came up because there would 
have been consequences for the ALTER if we had gone with the variable 
size idea, depending on how the ALTER was implemented.

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

Right. Altering the values is a schema change (and I'd argue that 
domains fall into the same boat). If you want user-editable entries, 
create a separate table.

Cheers

Tom