Re: JSON Function Bike Shedding

On Thu, Feb 21, 2013 at 1:16 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> Well, for case the of operator, it means whatever we reserve to mean.
> Very much agree on limitations of symbolic representation of behaviors
> (especially since some of the best ones were reserved by SQL or other
> acctors), so I think there is growing consensus that such things
> should get moved to functions. But functions are a lot less terse
> than operators so functions describing clearly defined behaviors are
> appreciated.
>
> So, get() means what *define it to mean*, but the definition should be
> consistent. If it's shorthand for "get from some multiple key/value
> container" then fine. If get() is just not specific enough -- let's
> at least try and go for something behavior specific (such as getMember
> or some such) before punting and resolving type specific function
> names.
>
> In fact, a an awful lot of $propsal's behaviors are in fact direct
> proxies for hstore behaviors, and a superficial think is suggesting
> that around 90% of hstore API would make sense in JSON terms (even
> though Andrew didn't implement all those behaviors and we're not going
> to ask him to). That to me is suggesting that tuple manipulation is a
> pretty general problem (hstore AKA tuple) and json only brings a
> couple of things to the table that isn't already covered there.
> Isn't it nice that you can document functions like avals/svals ONCE
> and not have to rewrite your triggers when you swap out hstore for
> json to get a couple extra behavior bits?

Naming the JSON stuff the same way we've already named the hstore
stuff is a somewhat promising idea, but it's hard for me to believe
we'd truly resist the urge to tinker. avals and svals are completely
opaque to me; without reading the manual I have no idea what those
things mean. If they had longer, more descriptive names it would be
more tempting. Still, if the behaviors line up closely enough for
government work and we want to match the names up as well, I think
that'd be tolerable.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company