Re: Removing pg_migrator limitations

Bruce Momjian <bruce(at)momjian(dot)us> 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.

regards, tom lane