On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@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