Re: jsonb and nested hstore

>
> Thank you for checking that.  Teodor's goal was that new-hstore be 100%
> backwards-compatible with old-hstore.  If we're breaking APIs, then it

That's true. Binary format is fully compatible unless old hstore value has more 
than 2^28 key-value pairs (256 mln which is far from reachable by memory 
requirements). The single issue is a GiST index, GIN index should be recreated 
to utilize new features.

> doesn't really work to force users to upgrade the type, no?
>
> Teodor, are these output changes things that can be made consistent, or
> do we need separate hstore and hstore2 datatypes?

Introducing types in hstore causes this incompatibility - but I don't think 
that's huge or even  big problem. In most cases application does quoting (sets 
"1" instead of just 1) to preserve SQL-injection and to protect hstore-forbidden 
characters in hstore. Keys leaves untouched - it could be only a string.

That's possible to introduce GUC variable for i/o functions which will control 
old "bug-to-bug" behavior. IMHO, this is much better option that stopping hstore 
development or split hstore to two branches.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/