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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
