On 11/29/2012 01:06 PM, Merlin Moncure wrote:
> so, just hashing out your proposal and making sure it's reasonable
> analogous implementation of xpath. Sleeping on it, I say mostly, but
> not quite. how about some changes for json_get:
>
> 1) return setof (key, value) in the style of jquery each().
> 2) we need some way of indicating in the keytext path that we want to
> unnest the collecton pointed to by keytext or to just return it. for
> example, ->* as indicator?
> 3) use double quotes, and make them optional (as hstore)
> 4) speaking of hstore, prefer => vs ->?So I don't think your modifications are well thought out.
>
> if you do at least #1 and #2, json_get I think can cover all the bases
> for parsing json, meaning you could reproduce the behaviors for each
> of your four proposed just as xpath does for xml. (you may still
> want to add them for posterity or performance though). so no need for
> json_each or json_array_unnest etc.
>
json_get is designed to return a single thing. What is more, returning a
(key, value) pair seems quite silly when you're passing the key in as an
argument. It's not designed to be json_path or json_query, and it's not
designed either to take a path expression as an argument. So I don't
think this is a good direction. Your proposed mods to json_get modify it
out of all recognition. If I offer you a horse and ask what colour you'd
like, asking for a lion instead isn't a good response :-)
(Repeating myself), I also suggest exposing the transform API so that it
will be easy to construct further functions as extensions. I'm not
trying to cover the field. The intention here is to provide some very
basic json accessors as core functions / operators.
cheers
andrew