Re: Removing pg_migrator limitations - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Removing pg_migrator limitations
Date
Msg-id 20091218215708.GS4055@alvh.no-ip.org
Whole thread Raw
In response to Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Removing pg_migrator limitations  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:

> > > > 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.
> 
> Well, I thought the idea was to set the system table oid to match the
> oids already in the user tables.  I realize that is not all system oids.
> What am I missing exactly?

I think the OIDs for user-defined arrays stored in table data are
element types, not the array type which is what you're pointing at with
the line you quote:

> > >     array_oid = GetNewOid(pg_type);

IMBFOS.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Removing pg_migrator limitations
Next
From: Bruce Momjian
Date:
Subject: Re: Removing pg_migrator limitations