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: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
