On Mon, Sep 16, 2013 at 8:57 AM, Chris Travers <ch...@2ndquadrant.com> wrote: >> On 16 September 2013 at 14:43 Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
