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
