Andrew Kane <andrew@chartkick.com> writes:
> Thanks everyone for the feedback. The current enum implementation requires
> you to create a new type and add labels outside a transaction prior to an
> insert.
Right ...
> Since enums have a fixed number of labels, this type of feature may be
> better off as a property you could add to text columns (as Thomas
> mentions). This would avoid issues with hitting the max number of labels.
... but you're not saying how you'd avoid the need for prior commit of the
labels. The sticking point for enums is that once a value has gotten into
a btree index, we can't ever lose the ability to compare that value to
others, or the index will be broken. So inserting an uncommitted value
into user tables has to be prevented.
Maybe there's a way to assign the labels so that they can be compared
without reference to any outside data, but it's not clear to me how
that would work.
regards, tom lane
