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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/