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.

diff --git a/contrib/hstore/hstore_io.c b/contrib/hstore/hstore_io.c
index aa7b7e1b3ef1c7f5c1974ab572146458593ff976..0c1d99a0150f656088e725bc44e905c5d6fa27b0 100644 (file)
--- 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(