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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +