Re: jsonb and nested hstore

Bruce Momjian <bruce(at)momjian(dot)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.

regards, tom lane