Tom Lane wrote: > Alvaro Herrera <alvhe...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
