Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 41d2c08

Browse files
committed
Make hstore_to_jsonb_loose match hstore_to_json_loose on what's a number.
Commit e09996f 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.
1 parent 52b6364 commit 41d2c08

File tree

1 file changed

+1
-42
lines changed

1 file changed

+1
-42
lines changed

contrib/hstore/hstore_io.c

+1-42
Original file line numberDiff line numberDiff line change
@@ -1387,7 +1387,6 @@ hstore_to_jsonb_loose(PG_FUNCTION_ARGS)
13871387
JsonbParseState *state = NULL;
13881388
JsonbValue *res;
13891389
StringInfoData tmp;
1390-
bool is_number;
13911390

13921391
initStringInfo(&tmp);
13931392

@@ -1423,50 +1422,10 @@ hstore_to_jsonb_loose(PG_FUNCTION_ARGS)
14231422
}
14241423
else
14251424
{
1426-
is_number = false;
14271425
resetStringInfo(&tmp);
1428-
14291426
appendBinaryStringInfo(&tmp, HSTORE_VAL(entries, base, i),
14301427
HSTORE_VALLEN(entries, i));
1431-
1432-
/*
1433-
* don't treat something with a leading zero followed by another
1434-
* digit as numeric - could be a zip code or similar
1435-
*/
1436-
if (tmp.len > 0 &&
1437-
!(tmp.data[0] == '0' &&
1438-
isdigit((unsigned char) tmp.data[1])) &&
1439-
strspn(tmp.data, "+-0123456789Ee.") == tmp.len)
1440-
{
1441-
/*
1442-
* might be a number. See if we can input it as a numeric
1443-
* value. Ignore any actual parsed value.
1444-
*/
1445-
char *endptr = "junk";
1446-
long lval;
1447-
1448-
lval = strtol(tmp.data, &endptr, 10);
1449-
(void) lval;
1450-
if (*endptr == '\0')
1451-
{
1452-
/*
1453-
* strol man page says this means the whole string is
1454-
* valid
1455-
*/
1456-
is_number = true;
1457-
}
1458-
else
1459-
{
1460-
/* not an int - try a double */
1461-
double dval;
1462-
1463-
dval = strtod(tmp.data, &endptr);
1464-
(void) dval;
1465-
if (*endptr == '\0')
1466-
is_number = true;
1467-
}
1468-
}
1469-
if (is_number)
1428+
if (IsValidJsonNumber(tmp.data, tmp.len))
14701429
{
14711430
val.type = jbvNumeric;
14721431
val.val.numeric = DatumGetNumeric(

0 commit comments

Comments
 (0)