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 | 21205.1249524797@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes: > 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. Renumbering type OIDs after-the-fact seems impossibly messy --- there's not even any support in the backend for changing the OID of an existing row, let alone any way to do it from the SQL level. And you'd have to find and fix all the references elsewhere in the system catalogs. And what about collisions? ISTM the only reasonable way to deal with this would be to have some way for pg_dump to emit commands to create types with specific OIDs. While we were at it, we might as well add the ability to specify toast-table OIDs so as to get rid of the kluge that's doing that now. At the moment it looks to me like pg_migrator has crashed and burned for 8.4, at least for general-purpose usage. We might be able to have support for this stuff in 8.5. But not being able to deal with any user-defined types is too much of a restriction to make it of general interest. regards, tom lane
В списке pgsql-hackers по дате отправления: