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. -- 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
