On 03/05/2014 09:07 PM, Peter Geoghegan wrote:
> It's hard to justify having a user-facing hstore2 on the grounds of
> backwards compatibility, and giving those stuck on hstore the benefit
> of all of these new capabilities. That's because we *cannot* really
> preserve compatibility, AFAICT. Many of the lines of the patch
> submitted are due to changes in the output format of hstore, and the
> need to update the hstore tests' expected results to reflect these
> changes. For example:
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
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?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
