On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> On 03/05/2014 09:39 AM, Bruce Momjian wrote: >>> So, I am going to ask a back-track question and ask why we can't move >>> hstore into core. Is this a problem with the oids of the hstore data >>> type and functions? Is this a pg_upgrade-only problem? Can this be >>> fixed? > >> Yes, pg_upgrade is the problem, and no, I can't see how it can be fixed. > >> Builtin types have Oids in a certain range. Non-builtin types have Oids >> outside that range. If you have a clever way to get over that I'd be all >> ears, but it seems to me insurmountable right now. > > More to the point: > > 1. Built-in types have predetermined, fixed OIDs. Types made by > extensions do not, and almost certainly will have different OIDs in > different existing databases. > > 2. There's no easy way to change the OID of an existing type during > pg_upgrade, because it may be on-disk in (at least) array headers. > > We could possibly get around #2, if we could think of a secure way > for array_out and sibling functions to identify the array type > without use of the embedded OID value. I don't know how we could > do that though, particularly in polymorphic-function contexts. > > Also, there might be other cases besides arrays where we've embedded > type OIDs in on-disk data; anyone remember?
composite types. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers