> 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/
