>
> 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/