Re: json casts
От | Peter Eisentraut |
---|---|
Тема | Re: json casts |
Дата | |
Msg-id | 538E3286.3040300@gmx.net обсуждение исходный текст |
Ответ на | Re: json casts (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: json casts
|
Список | pgsql-hackers |
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 <sfrost@snowman.net> writes: >>>> * Andrew Dunstan (andrew@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 behavior in json.c then that >>> objection doesn't apply, so I wouldn't complain. >>> >>> >> >> >> I wasn't proposing to add a cast, just to allow users to add one if >> they wanted. But I'm quite happy to go with special-casing timestamps, >> and leave the larger question for another time. >> >> > > > Here's a draft patch. I'm still checking to see if there are other > places that need to be fixed, but I think this has the main one. 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 routing through to_char().
В списке pgsql-hackers по дате отправления: