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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
