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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
