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