Re: Removing pg_migrator limitations

Tom Lane wrote:
> At the moment it appears that we need the following hacks:
>
> * 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 ...
>
> where the functions cause static variables to become set, and the
> core code gets changed to look like
>
>     if (next_table_oid)
>     {
>         newoid = next_table_oid;
>         next_table_oid = 0;
>     }
>     else
>         newoid = GetNewOid(...);
>
> in selected places where currently there's just a GetNewOid(...) call.
>
> * 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);
>
>     CREATE TYPE foo AS ENUM ();
>
>     select pg_migrator_add_enum_value(12347, 'bar', 12348);
>     select pg_migrator_add_enum_value(12347, 'baz', 12349);
>     ...
>
>
> I don't see any value in the placeholder-row approach Bruce suggests;
> AFAICS it would require significantly uglier backend hacks than the
> above because dealing with an already-present row would be a bigger
> code change.
>
> Comments?
>
>             
>   

That looks fairly workable. The placeholder idea seems like a bit of a 
potential footgun, so I like the idea that we can in some limited 
circumstances set the oids fairly directly.

cheers

andrew