Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
От | Andrew Dunstan |
---|---|
Тема | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
Дата | |
Msg-id | 4A7A4451.6050106@dunslane.net обсуждение исходный текст |
Ответ на | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
Список | pgsql-hackers |
Tom Lane wrote: > 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. 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). > > Oh, and pg_enum rows too. > > It seems doable, but we're certainly not going to back-patch > any such thing into 8.4 ... > > > Is there any danger that an oid used in, say, pg_enum in the old version will be used in the catalog bootstrap in the new version? cheers andrew
В списке pgsql-hackers по дате отправления: