Re: Removing pg_migrator limitations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing pg_migrator limitations
Date
Msg-id 14692.1261182456@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing pg_migrator limitations  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Removing pg_migrator limitations
Next
From: Alvaro Herrera
Date:
Subject: Re: Backup history file should be replicated in Streaming Replication?