Re: Removing pg_migrator limitations

Alvaro Herrera wrote:
> 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.

Oh, yea, sorry, I was just showing examples of where we get the oids ---
I have not researched the exact calls yet, but I am doing that now and
will apply a patch that adds C comments to the C structures to identify
them.  I figure it would be good to document this no matter what we do.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +