Re: BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: bouda(at)edookit(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON
Date: 2014-11-26 16:19:49
Message-ID: 15817.1417018789@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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 response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Dunstan 2014-11-26 16:48:00 Re: [HACKERS] BUG #12070: hstore extension: hstore_to_json_loose produces invalid JSON
Previous Message Tom Lane 2014-11-26 15:50:51 Re: BUG #12053: Strange behavior for numeric types with unspecified precision-scale

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-11-26 16:25:31 Re: Compiling C++ extensions on MSVC using scripts in src/tools
Previous Message Alex Shulgin 2014-11-26 16:10:13 Re: Follow up to irc on CREATE INDEX vs. maintenance_work_mem on 9.3