On Feb 22, 2013, at 9:37 AM, Robert Haas <robertmh...@gmail.com> wrote:
What I think is NOT tolerable is choosing a set of short but arbitrary
names which are different from anything that we have now and
pretending that we'll want to use those again for the next data type
that comes along. That's just wishful thinking. Programmers who
believe that their decisions will act as precedent for all future code
are almost inevitably disappointed. Precedent grows organically out
of what happens; it's very hard to create it ex nihilo, especially
since we have no clear idea what future data types we'll likely want
to add. Sure, if we add something that's just like JSON but with a
few extra features, we'll be able to reuse the names no problem. But
that's unlikely, because we typically resist the urge to add things
that are too much like what we already have. The main reason we're
adding JSON when we already have hstore is because JSON has become
something of a standard. We probably WILL add more "container" types
in the future, but I'd guess that they are likely to be as different
from JSON as JSON is from XML, or from arrays. I'm not convinced we
can define a set of semantics that are going to sweep that broadly.
Maybe. I would argue, however, that a key/value-oriented data type will always call those things
"keys" and "values". So keys() and vals() (or get_keys() and get_vals()) seems
pretty reasonable to me.
Anyway, back to practicalities, Andrew last posted:
I am going to go the way that involves the least amount of explicit casting or
array construction. So get_path() stays, but becomes non-variadic. get() can
take an int or variadic text[], so you can do:
get(myjson,0)
get(myjson,'f1')
get(myjson,'f1','2','f3')
get_path(myjson,'{f1,2,f3}')
I would change these to mention the return types:
get_json(myjson,0)
get_json(myjson,'f1')
get_json(myjson,'f1','2','f3')
get_path_json(myjson,'{f1,2,f3}')
And then the complementary text-returning versions:
get_text(myjson,0)
get_text(myjson,'f1')
get_text(myjson,'f1','2','f3')
get_path_text(myjson,'{f1,2,f3}')
I do think that something like length() has pretty good semantics across data
types, though. So to update the proposed names, taking in the discussion, I now
propose:
Existing Name Proposed Name
-------------------------- -------------------
json_array_length() length()
json_each() each_json()
json_each_as_text() each_text()
json_get() get_json()
json_get_as_text() get_text()
json_get_path() get_path_json()
json_get_path_as_text() get_path_text()
json_object_keys() get_keys()
json_populate_record() to_record()
json_populate_recordset() to_records()
json_unnest() get_values()
json_agg() json_agg()
I still prefer to_record() and to_records() to populate_record(). It just feels
more like a cast to me. I dislike json_agg(), but assume we're stuck with it.
But at this point, I’m happy to leave Andrew to it. The functionality is
awesome.
