Re: Removing pg_migrator limitations

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Removing pg_migrator limitations
Дата
Msg-id 22739.1261694452@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Removing pg_migrator limitations
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Removing pg_migrator limitations