On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > It seems only pg_type.oid is an issue for hstore. We can easily modify
> > pg_dump --binary-upgrade mode to suppress the creation of the hstore
> > extension. That should allow user hstore columns to automatically map
> > to the new constant hstore oid. We can also modify pg_upgrade to scan
> > all the user tables for any use of hstore arrays and perhaps composite
> > types and tell the user they have to drop and upgrade those table
> > separately.
>
> Yeah, and that doesn't seem terribly acceptable. Unless you think the
> field usage of hstore[] is nil; which maybe it is, I'm not sure what
> the usage patterns are like. In general it would not be acceptable
> at all to not be able to support migrations of array columns.
It would prevent migration of _hstore_ array columns, which might be
acceptable. If we say pg_upgrade can never decline an upgrade, we
basically limit changes and increase the odds of needing a total
pg_upgrade-breaking release someday to re-adjust everything.
I basically think that a split between contrib and core for the
internally same data type just isn't sustainable.
Another conern is that it doesn't seem we are sure if we want JSONB in
core or contrib, at least based on some comments, so we should probably
decide that now, as I don't think the decision is going to be any easier
in the future. And as discussed above, moving something from contrib to
core has its own complexities.
I think we also have to break out how much of the feeling that JSONB is
not ready is because of problems with the core/contrib split, and how
much of it is because of the type itself. I am suggesting that
core/contrib split problems are not symptomatic of data type problems,
and if address/address the core/contrib split issue, the data type might
be just fine.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +