JSON Function Bike Shedding - Mailing list pgsql-hackers

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. 

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 as
thelatter, with only one parameter. Same for json_get_as_text() and json_get_path_as_text(). 

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

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. 

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

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())

Even if nothing changes before release, I'm happy with the functionality Andrew has added. As I said, this is pure bike
shedding,but I believe naming things is important, so it's a discussion worth having. 

Best,

David