From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: json casts |
Date: | 2014-05-27 20:19:02 |
Message-ID: | 5384F336.3000804@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/27/2014 03:57 PM, Heikki Linnakangas wrote:
> On 05/27/2014 10:53 PM, Andrew Dunstan wrote:
>> I've been on the receiving end of a couple of mumbles about the fact
>> that the JSON rendering code ignores casts of builtin types to JSON.
>> This was originally done as an optimization to avoid doing cache lookups
>> for casts for things we knew quite well how to turn into JSON values
>> (unlike, say, hstore). However, there is at least one concrete case
>> where this has some possibly undesirable consequences, namely
>> timestamps. Many JSON processors, especially JavaScript/ECMAScript
>> processors, require timestamp values to be in ISO 8601 format, with a
>> 'T' between the date part and the time part, and thus they barf on the
>> output we produce for such values.
>
> I don't understand what ignoring casts of builtin types to JSON means.
> Can you give an example?
See src/backend/utils/adt/json.c:json_categorize_type() lines 1280-1300.
When rendering some value as part of a json string, if a cast exists
from the data type to json, then the cast function is used to render the
json instead of the type's normal output function, but only if it's not
a builtin type.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-05-27 20:30:44 | Re: Race condition within _bt_findinsertloc()? (new page split code) |
Previous Message | Heikki Linnakangas | 2014-05-27 19:57:00 | Re: json casts |