Re: jsonb and nested hstore

On Wed, Mar 5, 2014 at 11:32 AM, Bruce Momjian <bruce(at)momjian(dot)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