Re: Removing pg_migrator limitations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing pg_migrator limitations
Date
Msg-id 22739.1261694452@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.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 ofadd_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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Removing pg_migrator limitations
Next
From: Bruce Momjian
Date:
Subject: Re: Removing pg_migrator limitations