Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON

On 11/26/2014 11:48 AM, Andrew Dunstan wrote:
>
> On 11/26/2014 11:19 AM, Tom Lane wrote:
>> bouda(at)edookit(dot)com writes:
>>> The hstore_to_json_loose(hstore) produces an invalid JSON in the
>>> following
>>> case:
>>> SELECT hstore_to_json_loose(hstore(ARRAY ['name'], ARRAY ['1.'] :: TEXT
>>> []))
>>> Output: {"name": 1.}
>>> The actual output is indeed incorrect as JSON does not permit `1.` -
>>> it must
>>> be a string.
>> Yeah. The problem seems to be the ad-hoc (I'm being polite) code in
>> hstore_to_json_loose to decide whether a string should be treated as a
>> number. It does much more work than it needs to, and fails to have any
>> tight connection to the JSON syntax rules for numbers.
>>
>> Offhand, it seems like the nicest fix would be if the core json code
>> exposed a function that would say whether a string matches the JSON
>> number syntax. Does that functionality already exist someplace,
>> or is it too deeply buried in the JSON parser guts?
>>
>> regards, tom lane
>>
>>
>
>
>
> In json.c we now check numbers like this:
>
> JsonLexContext dummy_lex;
> bool numeric_error;
> ...
> dummy_lex.input = *outputstr == '-' ? outputstr + 1 : outputstr;
> dummy_lex.input_length = strlen(dummy_lex.input);
> json_lex_number(&dummy_lex, dummy_lex.input, &numeric_error);
>
> numeric_error is true IFF outputstr is a legal json number.
>
> Exposing a function to do this should be trivial.
>
>

Tom,

what do you want to do about this? In the back branches, exposing a
function like this would be an API change, wouldn't it? Perhaps there we
just need to pick up the 100 lines or so involved from json.c and copy
them into hstore_io.c, suitably modified. In the development branch I
thing adding the function to the API is the best way.

I don't mind doing the work once we agree what is to be done - in the
development branch it will be trivial.

cheers

andrew