On 08/23/2010 07:34 PM, Bruce Momjian wrote:
> 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.
>
I've just been taking another look at this suggestion. I think it will
work quite cleanly. As long as we add the enums in the correct order it
should just do the Right Thing (tm).
To answer your other question, Oid wraparound will not be a problem.
Will get coding.
cheers
andrew