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: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
