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.



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to