Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON
От | Andrew Dunstan |
---|---|
Тема | Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON |
Дата | |
Msg-id | 54760440.2080501@dunslane.net обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose
produces invalid JSON
Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON |
Список | pgsql-hackers |
On 11/26/2014 11:19 AM, Tom Lane wrote: > bouda@edookit.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. cheers andrew
В списке pgsql-hackers по дате отправления: