From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: JSON Function Bike Shedding |
Date: | 2013-02-22 17:50:33 |
Message-ID: | 1CCEA6E4-9B1F-4F0B-946D-9914CF028825@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Feb 22, 2013, at 9:37 AM, Robert Haas <robertmhaas(at)gmail(dot)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.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-02-22 19:58:37 | Re: pg_xlogdump |
Previous Message | Robert Haas | 2013-02-22 17:37:29 | Re: JSON Function Bike Shedding |