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