Re: Removing pg_migrator limitations

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