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

From Alvaro Herrera
Subject Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Date
Msg-id 20090806133229.GA7769@alvh.no-ip.org
Whole thread Raw
In response to Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Dimitri Fontaine wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:

> > 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.

There's already general purpose syntax for relation options which can be
used to get options that do not ultimately end up in
pg_class.reloptions.  An existing example is WITH (oids).  One such
option could be used here.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Adding error message "source"
Next
From: Werner Echezuria
Date:
Subject: Re: problem with splitting a string