Re: BUG #8676: Bug Money JSON

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, email(at)andersonloyola(dot)com(dot)br, pgsql-bugs(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #8676: Bug Money JSON
Date: 2013-12-27 22:23:38
Message-ID: 52BDFDEA.3000304@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


On 12/26/2013 01:17 PM, Andrew Dunstan wrote:
>
> On 12/17/2013 11:16 AM, Andrew Dunstan wrote:
>>
>> On 12/17/2013 10:31 AM, Tom Lane wrote:
>>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>>> On Wed, Dec 11, 2013 at 02:30:04PM +0000,
>>>>> email(at)andersonloyola(dot)com(dot)br wrote:
>>>>>> postgres=# SELECT to_json(a) FROM (VALUES(1000::money)) a(salario);
>>>>>> to_json
>>>>>> -----------------------
>>>>>> {"salario":$1,000.00}
>>>>>> (1 row)
>>>> Yeah. I'll have a look. In fact this looks like it's possibly a couple
>>>> of bugs. The JSON produced by the first query is not valid. It looks
>>>> like we might need to force money to text unconditionally.
>>> Isn't this simply failure to quote the string properly? What drives
>>> to_json's choice of whether to quote or not, anyway?
>>>
>>>
>>
>>
>> If it's numeric, it only quotes if it sees a non-numeric character,
>> defined thus:
>>
>> /* letters appearing in numeric output that aren't valid in a JSON
>> number */
>> #define NON_NUMERIC_LETTER "NnAaIiFfTtYy"
>>
>>
>> I forgot about money when I did that - some of this dates back to 9.2.
>>
>> I'm about to test the attached patch which should force money to be
>> quoted always.
>>
>>
>
>
> This turned out to be not such a good idea. Quite apart from anything
> else it doesn't handle domains over money at all well.
>
> The attached patch abandons the test described above, and instead
> passes the string from the output function to the json number lexer to
> see if it's a valid json number. A small adjustment to the API of
> that function was required to make it suitable for this use. This
> seems like a much more robust approach.
>
>

Applied.

cheers

andrew

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2013-12-28 03:50:37 Re: BUG #8702: psql \df+ translate_columns[] overflow and unexpected gettext translation
Previous Message Erik Rijkers 2013-12-27 22:22:52 Re: to_number nl_NL.utf8

Browse pgsql-hackers by date

  From Date Subject
Next Message Adrian Klaver 2013-12-27 22:34:52 Re: pg_upgrade & tablespaces
Previous Message Kevin Grittner 2013-12-27 22:17:47 Re: [BUG FIX] Version number expressed in octal form by mistake