Re: jsonb and nested hstore

> I guess this is down to the continued definition of gin_hstore_ops as
> an opclass with text storage?:
No, type of this storage describes type of keys. For gin_hstore_ops each key and 
each value will be stored as a text value. The root of problem is a JavaScript 
or/and our numeric type. In JavaScript (which was a base for json type) you need 
explicitly point type of compare to prevent unpredictable result.

 select '25.0'::numeric = '25'::numeric; ?column?
---------- t
but select '25.0'::numeric::text = '25'::numeric::text; ?column?
---------- f

and
select '{"a": 25}'::json->>'a' = '{"a": 25.0}'::json->>'a'; ?column?
---------- f

In pointed example inserted value has age: 25 but searching jsonb value has 
age:25.0.

>
> + CREATE OPERATOR CLASS gin_hstore_ops
> + DEFAULT FOR TYPE hstore USING gin
> + AS
> +     OPERATOR        7       @>,
> +     OPERATOR        9       ?(hstore,text),
> +     OPERATOR        10      ?|(hstore,text[]),
> +     OPERATOR        11      ?&(hstore,text[]),
> +     FUNCTION        1       bttextcmp(text,text),
> +     FUNCTION        2       gin_extract_hstore(internal, internal),
> +     FUNCTION        3       gin_extract_hstore_query(internal,
> internal, int2, internal, internal),
> +     FUNCTION        4       gin_consistent_hstore(internal, int2,
> internal, int4, internal, internal),
> +     STORAGE         text;
>
>

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/