Re: Removing pg_migrator limitations

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Removing pg_migrator limitations
Date: 2009-12-18 21:42:36
Message-ID: 20091218214235.GR4055@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-12-18 21:45:23 Re: Removing pg_migrator limitations
Previous Message Peter Eisentraut 2009-12-18 21:39:42 Re: PATCH: Add hstore_to_json()