Tom Lane wrote: > Bruce Momjian <[email protected]> writes: > > Tom Lane wrote: > >> The reason I don't want to do it that way is that then you need two > >> ugly kluges in the backend, not just one. With the zero-and-add-one > >> approach there is no need to have a "next enum oid" variable at all. > > > Uh, I still need that variable because that is how we are going to set > > the oid in EnumValuesCreate(), unless we want to add dummy oid-value > > arguments to that function for use only by the binary upgrade > > server-side function. > > Please go back and re-read what I suggested: you need a function along > the lines of > add_enum_member(enum-type, 'value name', value-oid) > and then there's no need for any saved state. So what if it has a > different signature from the other pg_migrator special functions? > It's not doing the same thing.
OK, right, I can get rid of the enum function that just sets the next oid value if I do all the enum value creation via function calls. I will work in that direction then. -- Bruce Momjian <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
