Hmmm... I'm having evil thoughts about putting a whole web application including templating inside of Postgres and just exposing a few functions via a web interface.
Don't worry I won't do it really but does anyone worry that Postgres is doing too much and that focus might be lost on being a reliable and fast relational DB? I haven't seen any signs of problems but I do have this slight concern with all the array/hstore/json features they have been adding recently.
I think it's impressive how quickly the Postgres world was able to adapt to the shifting needs of webapps and the whole nosql thing. The latest JSON features are a natural extension of the key-value & array stuff that has been around for years.
There's also a bunch of working focusing on replication enhancements that is underway; adding first-party replication tooling will be a huge reliability improvement for Postgres clusters.
I don't think it's that they lost focus, it's that the project is picking up steam.
Yes you are probably right. I really like Postgres, the attitude (reliability, standards etc.), the documentation, basically everything and don't want it to change too much.
It's worth looking at things like hstore and json through the history of the project. The project has always been one which has focused on how to manage complex data in a relatively relational way, but has tended to go where no other database has gone before (table inheritance for example).
Now, it is true that when you get into the advanced capabilities of the database you run into hard edges that just don't make much sense at first, in part because they represent real disputes regarding how everything is supposed to work. Composite types in fields and table inheritance are well known for these sorts of problems but once you get used to the ideosyncracies they aren't bad.
This is true for JSON too, as there is no real way to map nested composite types to JSON constructs both ways (you can do tuple -> json, but not json -> tuple if the json object is nested). But a lot of these things just take time.
I guess C++-like philosophy of "pay (with performance) only for what you use" applies here. If you're not using hstore/json/v8 it probably won't affect you. Also they keep doing solid work on the SQL front, just see http://www.postgresql.org/docs/devel/static/release-9-3.html.
I was a little hesitant to use hstore in my latest project, but it ended up being really cool.
I'm basically storing a trees of metadata that catalogs, in this case, a "season" of television as a root and then each individual episode as a leaf.
What I thought was really cool was that I can store the object references (as a self-referential foreign key) outside of the hstore: this means that the join I use when fetching the tree is still indexed and very inexpensive.
However the actual metadata itself is stored as an hstore payload -- which can be indexed in addition to being part of your query. The only downside is you lose a bit of typesafety since hstore is `text->text`.
It let me throw an application together without committing to a rigid schema, which was nice -- and it actually ends up being pretty easy to work with.
I just thought it was really cool how easy it was to separate the unstructured data, and the well-structured relation of that data.
I think you could turn JSON into XML with a little work, and then run xslt on it in the db ;-)
> Don't worry I won't do it really but does anyone worry that Postgres is doing too much and that focus might be lost on being a reliable and fast relational DB?
Not really. PostgreSQL has never been a purely relational DB. See table inheritance for example (another feature very easily misused but which makes some very difficult things very possible).
It isn't quite the same, but a large amount of configuration and content gets commingled in Drupal databases. It can make for interesting upgrade / migration challenges if you aren't careful.
That isn't evil at all, and I saw someone was actually working on doing that. For web apps that just need to expose a json api, we already just generate boilerplate code from the database anyways, we literally don't write any code for the webapp.
Postgresql continues to be better in real practical ways for us every release. I haven't see any features cause problems or interfere with other features. I am not concerned that it is going to happen.
Don't worry I won't do it really but does anyone worry that Postgres is doing too much and that focus might be lost on being a reliable and fast relational DB? I haven't seen any signs of problems but I do have this slight concern with all the array/hstore/json features they have been adding recently.