Bruce Momjian wrote: > Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > There are several pg_migrator limitations that appeared late in the 8.4 > > > development cycle and were impossible to fix at that point. I would > > > like to fix them for Postgres 8.5: > > > > > > o a user-defined composite data type > > > o a user-defined array data type > > > o a user-defined enum data type > > > > > > I have discussed this with Alvaro. I think pg_migrator needs the > > > ability to set the pg_type.oid and pg_enum.oid for user-defined > > > composites, arrays, and enums to match the values in the old server, and > > > hence match references to those rows in user data tables. > > > > To be more precise, the pg_enum.oid needs to be set for ENUM types; > > there's no need for setting the pg_type.oid (for ENUM types). I don't > > know about composites but I think the problem with user defined arrays > > is the OID of the element type, not the array itself. > > Yes, good point. I can see where the oids are assigned in our C code: > > oids[i] = GetNewOid(pg_enum); > > array_oid = GetNewOid(pg_type); > > I need a way of controlling that.
You're (partly?) missing my point which is that the important OID to control is the one that actually gets stored on table files. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
