Re: Removing pg_migrator limitations

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

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +