Re: JSON Function Bike Shedding

On 02/12/2013 02:18 PM, David E. Wheeler wrote:
> Hello Hackers,
>
> If you dislike bike-shedding (and who does?), delete this email and the ensuing thread right now. You have been
warned!
>
> I have been playing with Andrew’s JSON enhancements and really enjoying them. I am already using them in code I’m
developingfor production deployment in a month or two. Kudos! 
>
> However, I am not so keen on the function names. They all start with json_! This mostly feels redundant to me, since
thetypes of the parameters are part of the function signature. 

I don't have any problem getting rid of the json_ prefixes, except for
json_agg which I think should keep it (c.f. string_agg, array_agg).

> Therefore, I would like to propose different names:
>
> Existing Name                  Proposed Name
> --------------------------     ----------------------------------------
> json_array_length()             array_length() or length() or size()
> json_each()                     each_json()
> json_each_as_text()             each_text()
> json_get()                      get_json()
> json_get_as_text()              get_text()
> json_get_path()                 get_json()
> json_get_path_as_text()         get_text()
> json_object_keys()              get_keys()
> json_populate_record()          record() or row()
> json_populate_recordset()       records() or rows()
> json_unnest()                   get_values()
> json_agg()                      collect_json()
>
> Note that I have given json_get() and json_get_path() the same names, as it seems to me that the former is the same
asthe latter, with only one parameter. Same for json_get_as_text() and json_get_path_as_text(). 

I will take some of this under advisement. Note that
json_populate_record's name was taken from hstore's populate_record, so
if we're trying to use similar names then it should possibly be just
populate_record. Or if that's still a bit long I would accept to_record.


>
> One nice thing about get_values() as opposed to json_unnest(), is that it could be used to fetch the values from a
JSONobject as well as an array. (BTW, I think unnest is not a good name at all, since unlike the SQL unnest() function,
itdoesn't actually unnest (flatten) the entire array). 

I think Merlin's suggestion if unwrap might be good. Or simply
"elements()" might work.

>
> As for the operators, as previously discussed, I'm happy with either -> or ~> (and ->> or ~>>, of course). But I'm
wonderingif the same operator couldn't be used when an array is on the RHS. I mean, having #> to that it doesn't have
tobe cast is nice, too, but I think it'd be nice if an array would work with -> and ->>, too. 

The point of using different operator names is that if there's an array
literal postgres will convert it to an array. If the operator names are
the same it will treat it as a text key instead. Being able to type
    my_json #>> '{f1,0,f2,3,f3}'

is nice. Of course, we could duplicate the operators, but I generally
prefer not to do that.

>
> AS for #> and #>>, what about @> and @>> instead? Or am I just too much the Perl hacker for thinking that @ is a nice
mnemonicfor "array"? 

Probably. I deliberately avoided @> because it's used elsewhere to mean
"contains" and using it for something quite different here might be
confusing.

>
> And finally, a couple of feature requests, which can be taken with a shaker of salt -- or as ideas for 9.4 -- and are
mostlystolen from hstore: 
>
> * An exists() function (and ? operator) similar to hstore
> * A defined() function
> * A delete() function
> * A slice() function
> * A concatenation function and operator
> * union, intercept, and except operators and/or functions
> * Perhaps some set-returning functions (select_keys(), select_values())


I think this is beyond bikeshedding. Apparently you have missed the
existence of json_object_keys().

The new API makes many or all of these things possible to do with
relative ease as extensions (See my possibly upcoming talk on the subject.)

cheers

andrew