diff options
author | Tom Lane | 2016-02-03 17:03:50 +0000 |
---|---|---|
committer | Tom Lane | 2016-02-03 17:04:02 +0000 |
commit | 41d2c081ce659f40dec3eb9efc647082aa775eb4 (patch) | |
tree | c18745d6f0efb3cb2bf8ddfe67fd3ba7aa901651 | |
parent | 52b63649fc5ff5d86227b8905e1c79cd9ceddf4c (diff) |
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.
-rw-r--r-- | contrib/hstore/hstore_io.c | 43 |
1 files changed, 1 insertions, 42 deletions
diff --git a/contrib/hstore/hstore_io.c b/contrib/hstore/hstore_io.c index aa7b7e1b3e..0c1d99a015 100644 --- a/contrib/hstore/hstore_io.c +++ b/contrib/hstore/hstore_io.c @@ -1387,7 +1387,6 @@ hstore_to_jsonb_loose(PG_FUNCTION_ARGS) JsonbParseState *state = NULL; JsonbValue *res; StringInfoData tmp; - bool is_number; initStringInfo(&tmp); @@ -1423,50 +1422,10 @@ hstore_to_jsonb_loose(PG_FUNCTION_ARGS) } else { - is_number = false; resetStringInfo(&tmp); - appendBinaryStringInfo(&tmp, HSTORE_VAL(entries, base, i), HSTORE_VALLEN(entries, i)); - - /* - * don't treat something with a leading zero followed by another - * digit as numeric - could be a zip code or similar - */ - if (tmp.len > 0 && - !(tmp.data[0] == '0' && - isdigit((unsigned char) tmp.data[1])) && - strspn(tmp.data, "+-0123456789Ee.") == tmp.len) - { - /* - * might be a number. See if we can input it as a numeric - * value. Ignore any actual parsed value. - */ - char *endptr = "junk"; - long lval; - - lval = strtol(tmp.data, &endptr, 10); - (void) lval; - if (*endptr == '\0') - { - /* - * strol man page says this means the whole string is - * valid - */ - is_number = true; - } - else - { - /* not an int - try a double */ - double dval; - - dval = strtod(tmp.data, &endptr); - (void) dval; - if (*endptr == '\0') - is_number = true; - } - } - if (is_number) + if (IsValidJsonNumber(tmp.data, tmp.len)) { val.type = jbvNumeric; val.val.numeric = DatumGetNumeric( |