Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
От | Tom Lane |
---|---|
Тема | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
Дата | |
Msg-id | 21450.1249525780@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Re: [Pg-migrator-general] Composite types break pg_migrated
tables
Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
Список | pgsql-hackers |
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 ... regards, tom lane
В списке pgsql-hackers по дате отправления: