On 06/03/2014 04:45 PM, Tom Lane wrote:
Peter Eisentraut writes:
This was solved back in the day for the xml type, which has essentially
the same requirement, by adding an ISO-8601-compatible output option to
EncodeDateTime(). See map_sql_value_to_xml_value() in xml.c. You ought
to be able t
Peter Eisentraut writes:
> This was solved back in the day for the xml type, which has essentially
> the same requirement, by adding an ISO-8601-compatible output option to
> EncodeDateTime(). See map_sql_value_to_xml_value() in xml.c. You ought
> to be able to reuse that. Seems easier than rou
On 5/28/14, 6:48 PM, Andrew Dunstan wrote:
>
> On 05/27/2014 07:25 PM, Andrew Dunstan wrote:
>>
>> On 05/27/2014 07:17 PM, Tom Lane wrote:
>>> Stephen Frost writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
> Given that this would be a hard coded behaviour change, is it too
> lat
On 05/27/2014 07:25 PM, Andrew Dunstan wrote:
On 05/27/2014 07:17 PM, Tom Lane wrote:
Stephen Frost writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
Given that this would be a hard coded behaviour change, is it too
late to do this for 9.4?
No, for my 2c.
If we do it by adding casts t
On 05/27/2014 11:55 PM, Robert Haas wrote:
On Tue, May 27, 2014 at 5:00 PM, Tom Lane wrote:
I'd be inclined to think a more useful answer to this issue would be to
make json.c special-case timestamps, as it already does for numerics.
I wonder if anyone besides me is nervous about changing the
On Tue, May 27, 2014 at 5:00 PM, Tom Lane wrote:
> I'd be inclined to think a more useful answer to this issue would be to
> make json.c special-case timestamps, as it already does for numerics.
I wonder if anyone besides me is nervous about changing the semantics
here. It seems like the sort of
On 05/27/2014 07:17 PM, Tom Lane wrote:
Stephen Frost writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
Given that this would be a hard coded behaviour change, is it too
late to do this for 9.4?
No, for my 2c.
If we do it by adding casts then it'd require an initdb, so I'd vote
against
Stephen Frost writes:
> * Andrew Dunstan (and...@dunslane.net) wrote:
>> Given that this would be a hard coded behaviour change, is it too
>> late to do this for 9.4?
> No, for my 2c.
If we do it by adding casts then it'd require an initdb, so I'd vote
against that for 9.4. If we just change be
* Andrew Dunstan (and...@dunslane.net) wrote:
> >>I'd be inclined to think a more useful answer to this issue would be to
> >>make json.c special-case timestamps, as it already does for numerics.
> >>
> >>
>
> OK, that's another approach.
I'm all for doing this for JSON, but i
On 05/27/2014 05:43 PM, Hannu Krosing wrote:
On 05/27/2014 11:00 PM, Tom Lane wrote:
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 rende
On 05/27/2014 11:00 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> 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 built
Andrew Dunstan writes:
> 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
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 ca
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
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, h
15 matches
Mail list logo
