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 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.
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 as the 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 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).
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 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.
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 mnemonic for "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 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())
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
