Re: data to json enhancements
От | Tom Lane |
---|---|
Тема | Re: data to json enhancements |
Дата | |
Msg-id | 28661.1348681588@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | data to json enhancements (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: data to json enhancements
Re: data to json enhancements Re: data to json enhancements is JSON really "a type" (Re: data to json enhancements) |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > Drawing together various discussions both here and elsewhere (e.g. the > PostgresOpen hallway track) I propose to work on the following: > 1. make datum_to_json() honor a type's cast to json if it exists. The > fallback is to use the type's string representation, as now. > 2. add a cast hstore -> json (any others needed for core / contrib types ?) > 3. add a to_json(anyelement) function > 4. add a new aggregate function json_agg(anyrecord) -> json to simplify > and make more effecient turning a resultset into json. > Comments welcome. ISTM the notion of to_json(anyelement) was already heavily discussed and had spec-compliance issues ... in fact, weren't you one of the people complaining? What exactly does #3 mean that is different from the previous thread? Also, on reflection I'm not sure about commandeering cast-to-json for this --- aren't we really casting to "json member" or something like that? The distinction between a container and its contents seems important here. With a container type as source, it might be important to do something different if we're coercing it to a complete JSON value versus something that will be just one member. I'm handwaving here because I don't feel like going back to re-read the RFC, but it seems like something that should be considered carefully before we lock down an assumption that there can never be a difference. regards, tom lane
В списке pgsql-hackers по дате отправления: