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 table... David J.
