Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Date
Msg-id 87tz0lcpgh.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Andrew Dunstan <andrew@dunslane.net> writes:
>> preventing a clash might be fairly difficult.
>
> Yeah, I was just thinking about that.  The easiest way to avoid
> collisions would be to make pg_dump (in --binary-upgrade mode)
> responsible for being sure that *every* new pg_type and pg_class row
> OID matches what it was in the old DB. 

As we already have WITH OIDS for CREATE TABLE command, maybe adding
support for WITH OID ... to the necessary commands would do the trick?

Instead of messing with pg_type, pg_dump would then have to issue a OID
'decorated' command such as CREATE TYPE footype ... WITH OID 27604;

> We could stop doing that
> once we have all the user tables in place --- I don't believe it's
> necessary to preserve the OIDs of user indexes.  But we need to
> preserve toast table OIDs, and toast table index OIDs too if those
> are created at the same time they are now (else we risk one of them
> colliding with a toast table OID we want to create later).

It seems harder to come up with a general purpose syntax to support the
feature in case of toast tables, though.

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: 8.4 win32 shared memory patch
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables