Re: Proposal: json_populate_record and nested json objects
От | Merlin Moncure |
---|---|
Тема | Re: Proposal: json_populate_record and nested json objects |
Дата | |
Msg-id | CAHyXU0zE5YMqnYzScKvJEQewD2E_hu9V8ZirO87wwBqqu22yag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: json_populate_record and nested json objects (Chris Travers <chris@2ndquadrant.com>) |
Список | pgsql-hackers |
On Mon, Sep 16, 2013 at 8:57 AM, Chris Travers <chris@2ndquadrant.com> wrote: >> On 16 September 2013 at 14:43 Merlin Moncure <mmoncure@gmail.com> wrote: > >> >> Huge +1 on on this. Couple random thoughts: >> >> *) Hard to see how you would structure this as an extension as you're >> adjusting the behaviors of existing functions, unless you wanted to >> introduce new function names for testing purposes? > > Yeah, and reading the source, it looks like some parts of the JSON parsing > code will have to be rewritten because the nested object errors are thrown > quite deeply in the parsing stage. It looks to me as if this will require > some significant copying as a POC into a new file with different publicly > exposed function names. ISTM that's not worth it then. >> *) Would like to at least consider being able to use casting syntax as >> a replacement for "populate_record" and (the missing) "populate_array" >> for most usages. > > Yes. I am trying to figure out how best to do this at present. Initially I > think I would be happy to settle for casts wrapping functions which > themselves just wrap the call to populate_record. right. > What I will probably do for my POC is expose the following methods: > > 1. json_populate_type() hm if you're going to name it that way, prefer json_populate_value(). (or maybe _scalar() or _datum()). but we have to_json(), so how about from_json()? merlin
В списке pgsql-hackers по дате отправления: