On 03/05/2014 11:44 AM, Bruce Momjian wrote:
> 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.
>
Splitting out jsonb to an extension is going to be moderately painful.
The json and jsonb functions share some code that's not exposed (and
probably shouldn't be). It's not likely to be less painful than
implementing the hstore GIN/GIST ops for jsonb, I suspect the reverse.
cheers
andrew
