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 | 4A7A3D5E.2020909@dunslane.net обсуждение исходный текст |
Ответ на | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables (Bruce Momjian <bruce@momjian.us>) |
Ответы |
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_migratedtables |
Список | pgsql-hackers |
Bruce Momjian wrote: > Do we have no composite types in the regression tests, or do we not > store any in the database? Same the enums. > > Looks like the enum regression tests at least drop all their tables :-( > To allow pg_migrator to work, I would need to reserve the oids in > pg_type, import the dump, and renumber the pg_type entries (and > everything pointing to them) to the proper pg_type.oid. The big problem > there is that I don't have access at the SQL level to set or change > oids. I am afraid the oid remumbering is something we would have to do > in the backend by walking through the pg_depend entries for the pg_type > row. Yuck. Yeah. Maybe we need some special way of setting the oids explicitly. But preventing a clash might be fairly difficult. Excluding every database that has a composite/array-of user-defined-type/enum type would be pretty nasty. After all, these are features we boast of. cheers andrew
В списке pgsql-hackers по дате отправления: