On Wed, Mar 5, 2014 at 11:32 AM, Bruce Momjian <br...@momjian.us> wrote: > So, now knowing that hstore2 is just hierarchical hstore using the same > hstore type name, you are saying that we are keeping the > non-hierarchical code in contrib, and the rest goes into core --- that > makes sense, and from a code maintenance perspective, I like that the > non-hierarchical hstore code is not going in core.
Yeah. 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: *************** select slice(hstore 'aa=>1, b=>2, c=>3', *** 759,779 **** (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b']); ! slice ! -------------------- ! "b"=>"2", "c"=>"3" (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['aa','b']); ! slice ! --------------------- ! "b"=>"2", "aa"=>"1" (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']); ! slice ! ------------------------------- ! "b"=>"2", "c"=>"3", "aa"=>"1" (1 row) select pg_column_size(slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b'])) --- 777,797 ---- (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b']); ! slice ! ---------------- ! "b"=>2, "c"=>3 (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['aa','b']); ! slice ! ----------------- ! "b"=>2, "aa"=>1 (1 row) select slice(hstore 'aa=>1, b=>2, c=>3', ARRAY['c','b','aa']); ! slice ! ------------------------- ! "b"=>2, "c"=>3, "aa"=>1 (1 row) I could believe that there was at least something to be said for a user-visible hstore2 if the new capabilites were available without breaking application code, but it seems that isn't the case. Anyone who is going to have to deal with some of this kind of incompatibility one way or the other might as well switch over to jsonb entirely. When changing aspects of our output format like this, the impact on users is more or less a step function (of the number of small changes). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
