pgsql: Make hstore_to_jsonb_loose match hstore_to_json_loose on what's - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Make hstore_to_jsonb_loose match hstore_to_json_loose on what's
Date
Msg-id E1aR0qk-00004x-Ix@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Make hstore_to_jsonb_loose match hstore_to_json_loose on what's a number.

Commit e09996ff8dee3f70 removed some ad-hoc code in hstore_to_json_loose
that determined whether an hstore value string looked like a number,
in favor of calling the JSON parser's is-it-a-number code.  However,
it neglected the fact that the exact same code appeared in
hstore_to_jsonb_loose.

This is not a bug, exactly, because the requirements on the two functions
are not the same: hstore_to_json_loose must accept only syntactically legal
JSON numbers as numbers, or it will produce invalid JSON output, as per bug
#12070 which spawned the prior commit.  But hstore_to_jsonb_loose could
accept anything that numeric_in will eat, other than Inf and NaN.

Nonetheless it seems surprising and arbitrary that the two functions don't
use the same rules for what is a number versus what is a string; especially
since they did use the same rules before the aforesaid commit.  For one
thing, that means that doing hstore_to_json_loose and then casting to jsonb
can produce results different from doing just hstore_to_jsonb_loose.

Hence, change hstore_to_jsonb_loose's logic to match hstore_to_json_loose,
ie, hstore values are treated as numbers when they match the JSON syntax
for numbers.

No back-patch, since this is more in the nature of a definitional change
than a bug fix.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/41d2c081ce659f40dec3eb9efc647082aa775eb4

Modified Files
--------------
contrib/hstore/hstore_io.c | 43 +------------------------------------------
1 file changed, 1 insertion(+), 42 deletions(-)


pgsql-committers by date:

Previous
From: Robert Haas
Date:
Subject: pgsql: Code review for commit dc203dc3ac40a4b02b92fb827848a547d2957153.
Next
From: Peter Eisentraut
Date:
Subject: pgsql: doc: Fix stand-alone INSTALL file build