Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to the flagship feature (jsonb), particularly, "binary
storage for nested structures and indexing. Their work was sponsored
by Engine Yard".
As for the old hstore I think it'd be nice to add gin_hstore_hash_ops,
so hstore users will benefit from 9.4 release. There is no
compatibiliy issue, so I think this could be harmless.
Oleg
On Thu, Mar 6, 2014 at 7:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
>
> regards, tom lane
