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 developing for 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 the types 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 the latter, 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 object as well as an array. (BTW, I 
think unnest is not a good name at all, since unlike the SQL unnest() function, 
it doesn't actually 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 wondering if the same operator couldn't be 
used when an array is on the RHS. I mean, having #> to that it doesn't have to 
be 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 mnemonic for "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 mostly stolen 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








-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to