On Wed, Dec 2, 2009 at 11:28 AM, Bruce Momjian <br...@momjian.us> wrote: >> > >> > set next_pg_class_oid = 12345; >> > set next_pg_type_oid = 12346; >> > set next_toast_table_oid = ... >> > set next_toast_index_oid = ... >> > >> > and finally it could do CREATE TABLE. ?CREATE TYPE would only need >> > next_pg_type_oid (except for a composite type). >> >> Is this idea still on the table for 8.5? > > Well, pg_migrator still has these restrictions that will apply to > migrations to 8.5: > > pg_migrator will not work if a user column is defined as: > > o a user-defined composite data type > o a user-defined array data type > o a user-defined enum data type > > You must drop any such columns and migrate them manually. > > Having 'next_pg_type_oid' would fix that. The other three settings are > already handled by pg_migrator code. Having those three settings would > allow me to remove some pg_migrator code once we removed support for > migrations to 8.4.
I also have a personal interest for non pg_migrator reasons. The basic problem is that there is no way to make oids consistent between databases which causes headaches for things like migration and direct transfer of data between databases in binary. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
