On Thu, Feb 21, 2013 at 1:16 PM, Merlin Moncure <mmonc...@gmail.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers