summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane2016-02-03 17:03:50 +0000
committerTom Lane2016-02-03 17:04:02 +0000
commit41d2c081ce659f40dec3eb9efc647082aa775eb4 (patch)
treec18745d6f0efb3cb2bf8ddfe67fd3ba7aa901651
parent52b63649fc5ff5d86227b8905e1c79cd9ceddf4c (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.c43
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(