Re: Removing pg_migrator limitations

Alvaro Herrera <alvherre(at)commandprompt(dot)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