Andrew Dunstan wrote: > > Attached is a WIP patch that allows enums to be extended with additional > labels arbitrarily. As previously discussed, it works by adding an > explicit sort order column to pg_enum. It keeps track of whether the > labels are correctly sorted by oid value, and if so uses that for > comparison, so the possible performance impact on existing uses, and on > almost all cases where a label is added at the end of the list, should > be negligible. > > Open items include > > * some additional error checking required > * missing documentation > * pg_upgrade considerations
I looked at the pg_upgrade ramifications of this change and it seems some adjustments will have to be made. Right now pg_upgrade creates an empty enum type: CREATE TYPE etest AS ENUM (); and then it calls EnumValuesCreate() to create the enum labels. EnumValuesCreate() is called from within DefineEnum() where the enum type is created, and that assumes the enums are always created initially sorted. That would not be true when pg_upgrade is calling EnumValuesCreate() directly with oid assignment as part of an upgrade. I think the cleanest solution would be to modify pg_dump.c so that it creates an empty ENUM type like before, but uses the new ALTER TYPE myenum ADD 'newlabel' syntax to add the enum labels (with oid assignment like we do for CREATE TYPE, etc.) The existing code had to hack to call EnumValuesCreate() but with this new syntax it will no longer be necessary. The call to EnumValuesCreate() for enums is the only time pg_upgrade_support calls into a function rather than just assigning an oid to a global variable, so it would be great to remove that last direct function call usage. Does this code handle the case where CREATE ENUM oid wraps around while the enum label oids are being assigned? Does our existing code handle that case? I also noticed you grab an oid for the new type using the oid counter without trying to make it in sorted order. Seems that would be possible for adding enums to the end of the list, and might not be worth it. A quick hack might be to just try of an oid+1 from the last enum and see if that causes a conflict with the pg_enum.oid index. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers