Re: json casts

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

In response to

Responses

Browse pgsql-hackers by date

  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