Tom Lane wrote:
> * ability to control the OIDs assigned to user tables and types.
> Because a table also has a rowtype, this means at least two separate
> state variables. And we already knew we had to control the OIDs
> assigned to toast tables. I'm imagining dump output like
>
> 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?
> * ability to control the OIDs assigned to enum values. To keep this
> sane I think the easiest way is to have pg_migrator have a function
> that adds one value with a predetermined OID to an existing enum.
> So instead of CREATE TYPE foo AS ENUM ('bar', 'baz', ...)
> I envision the --binary_upgrade dump output looking like
>
> -- 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 ();
>
> select pg_migrator_add_enum_value(12347, 'bar', 12348);
> select pg_migrator_add_enum_value(12347, 'baz', 12349);
on which we could perhaps use "foo" as a reference instead of the OID
value. However, I think array and composite types need a specific type
OID, so the set_next_type_oid function would still be necessary.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support