| 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: | Whole Thread | Raw Message | 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 |