On Friday, March 25, 2016, Andrew Dunstan <and...@dunslane.net> wrote:

> On 03/25/2016 04:13 AM, Matthias Kurz wrote:
>> Hopefully at the commitfest at least the transaction limitation
>> will/could be tackled - that would help us a lot already.
> I don't believe anyone knows how to do that safely. Enums pose special
> problems here exactly because unlike all other types the set of valid
> values is mutable.

Yeah, I'm not sure there is much blue sky here as long as the definition of
an enum is considered system data.  It probably needs to be altered so that
a user can create a table of class enum with a known layout that PostgreSQL
can rely upon to perform optimizations and provide useful behaviors - at
least internally.  The most visible behavior being displaying the label
while ordering using its position.

The system, seeing a data type of that class, would have an implicit
reference between columns of that type and the source table.
You have to use normal cascade update/delete/do-nothing while performing
DML on the source table.

In some ways it would be a specialized composite type, and we could
leverage that to you all the syntax available for those - but without
having a different function for each differently named enum classed table
since they all would share a common structure, differing only in name.  But
the tables would be in user space and not a preordained relation in
pg_catalog.  Maybe require they all inherit from some template but empty

David J.

Reply via email to