On 03/26/2016 12:35 AM, David G. Johnston wrote:
On Friday, March 25, 2016, Andrew Dunstan <and...@dunslane.net
<mailto: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...
We don't have the luxury of being able to redesign this as a green
fields development.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
