Re: Removing pg_migrator limitations

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Removing pg_migrator limitations
Дата
Msg-id 14692.1261182456@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Removing pg_migrator limitations  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Removing pg_migrator limitations
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> select pg_migrator_set_next_table_oid(123456);
>> select pg_migrator_set_next_type_oid(12347);
>> select pg_migrator_set_next_toast_table_oid(123458);
>> 
>> CREATE TABLE ...

> Do we also need a knob for the table type's array type?

Well, we wouldn't care about the oid of the array type, except that if
the backend is allowed to assign it on its own, it might eat an oid that
we're going to need later for another type.  So yeah, array oids too.
(The above is just a sketch, I don't promise it's complete ;-))

>> -- force the OID of the enum type itself
>> select pg_migrator_set_next_type_oid(12347);

> This part isn't necessary AFAIK, except to be used as reference here:

>> CREATE TYPE foo AS ENUM ();

Exactly.  We have to assign the oid of the enum type just as much as any
other type.  Basically, to avoid collisions we'll need to ensure we nail
down the oids of every pg_class and pg_type row to be the same as they
were before.  We might have to nail down relfilenodes similarly, not
sure yet.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Removing pg_migrator limitations
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Backup history file should be replicated in Streaming Replication?