From 41d2c081ce659f40dec3eb9efc647082aa775eb4 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 3 Feb 2016 12:03:50 -0500 Subject: [PATCH] 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. --- contrib/hstore/hstore_io.c | 43 +------------------------------------- 1 file changed, 1 insertion(+), 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(