Bruce Momjian wrote: > Bruce Momjian wrote: > > I looked at DefineEnum() and basically adding the ability to add enums > > would put the new enum after the existing ones unless the OID counter > > has wrapped around and is less than the oid counter at the time the enum > > type was created, in which case it will be listed as before the existing > > values. I wasn't aware enum ordering is something we tried to maintain. > > One issue is that we are not supporting the addition of enum values even > > for people who don't care about the ordering of enums (which I bet might > > be the majority.) > > > > I can think of a few approaches for pg_migrator: > > > > 1) Create an oid array in a permanent memory context and have > > DefineEnum() read from that. > > 2) Renumber the enum entries after they are created but before > > any of their oids are stored in user tables. > > > > Both can be done by pg_dump with proper server-side functions. The > > problem with #2 are cases where the old and new oid ranges overlap, > > e.g.: > > I now think the easiest solution will be to have pg_dump create the enum > with a single dummy value, delete the pg_enum dummy row, and then call a > modified version of EnumValuesCreate() to insert row by row into > pg_enum, with specified oids.
I thought of a cleaner approach. CREATE TYPE ENUM will create one enum with the specified oid, and then a server-side function will call EnumValuesCreate() be used to add each additional enum with a specified oid --- no deleting necessary. I will start working on a patch for this. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers