Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON |
| Дата | |
| Msg-id | 15817.1417018789@sss.pgh.pa.us обсуждение исходный текст |
| Ответы |
Re: [BUGS] BUG #12070: hstore extension: hstore_to_json_loose
produces invalid JSON
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера