Bruce Momjian <bruce@momjian.us> writes: > OK, just to summarize:
> JSONB and everything it shares with hstore will be in core > hstore-specific code stays in contrib > hstore contrib will create an hstore type to call contrib and core code > 9.4 hstore has some differences from pre-9.4
I've got a problem with the last part of that. AFAICS, the value proposition for hstore2 largely fails if it's not 100% upward compatible with existing hstore, both as to on-disk storage and as to application- visible behavior. If you've got to adapt your application anyway, why not switch to JSONB which is going to offer a lot of benefits in terms of available code you can work with?
Although I've not looked at the patch, it was claimed upthread that there were changes in the I/O format for existing test cases, for example. IMO, that's an absolute dead no-go.
> The question is whether we change/improve hstore in 9.4, or create an > hstore2 that is the improved hstore for 9.4 and keep hstore identical to > pre-9.4. That last option looks an awful like the dreaded VARCHAR2.
I think hstore2 as a separate type isn't likely to be a win either.
The bottom line here is that hstore2 is more or less what we'd agreed to doing back at the last PGCon, but that decision has now been obsoleted by events in the JSON area. If jsonb gets in, I think we probably end up rejecting hstore2 as such. Or at least, that's what we should do IMO. contrib/hstore is now a legacy type and we shouldn't be putting additional work into it, especially not work that breaks backwards compatibility.
(not read up on the full details of the thread, sorry if I'm re-iterating something)
I think we definitely want/need to maintain hstore compatibility. A completely separate hstore2 type that's not backwards compatible makes very little sense.
However, if the new hstore type (compatible with the old one) is the wrapper around jsonb, rather than the other way around, I don't see any problem with it at all. Most future users are almost certainly going to use the json interfaces, but we don't want to leave upgraded users behind. (But of course it has to actually maintain backwards compatibility for that argument to hold)