Re: Removing pg_migrator limitations

Tom Lane wrote:
> 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

I assume you meant pg_type and pg_class above, or I hope you were.

> were before.  We might have to nail down relfilenodes similarly, not
> sure yet.

Yea, piggybacking on Alvaro's idea for pg_enum, if we set all the
pg_type oids we can clearly do this with no placeholders necessary.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +