It's reasonably easy to wrap the SQL involved in calling stored procedures.[1]
The JSON in 9.3 is almost good enough for this. It doesn't handle nested data structures to sql nested complex types properly, and so it won't quite get you there but otherwise agreed.
I.e. to make it work currently you have to slice and dice the JSON in some fun ways first. I find it less painful to just handle the complex type serialization/deserialization on the client side.
Yes, it is easy, but people using Mongo, CouchDB etc... will argue that not having to do it at all is better, and will use that argument to justify their choice.
Same idea as ORMs... Making any CRUD operation is easy in SQL, why did we need ORMs? Yet, there is a fragment of the population who wouldn't use a database they couldn't talk to through an ORM. Today, there is a segment of programers that won't use a database if they can't PUT({"name": "Big Bird", "address": "123 Sesame street"}), because, you know, that's the modern way to do things.
No. Adding support for a json NoSQL like interface doesn't remove the SQL access. You could let the front end guys do Create Update Retrieve by primary key using the json interface, while the backend analysis guys use SQL through the normal SQL driver.
I think you misunderstood my point. The "modern" way seems to be to avoid SQL using either NoSQL or something like an ORM.
Personally I prefer to tackle this from the other side with stored procedures and service locators so my application code is free of SQL (aside from the service locator), and all my SQL is in .sql files.....
The JSON in 9.3 is almost good enough for this. It doesn't handle nested data structures to sql nested complex types properly, and so it won't quite get you there but otherwise agreed.
I.e. to make it work currently you have to slice and dice the JSON in some fun ways first. I find it less painful to just handle the complex type serialization/deserialization on the client side.
[1] See https://github.com/einhverfr/PGObject-Simple-Role