Horton
Menu

Re: Removing pg_migrator limitations

Joe Conway <mail@joeconway.com>

View thread
From: Joe Conway <mail@joeconway.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: 2009-12-19T01:27:06Z
Lists: pgsql-hackers 
On 12/18/2009 04:09 PM, 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 ...

I like this approach overall, but wonder if it would be better to do:

	select pg_migrator_set_next_oid('table', 123456);
	select pg_migrator_set_next_oid('type', 12347);
	select pg_migrator_set_next_oid('toast_table', 123458);

etc. Later we could easily add other supported objects...


Joe