As a note here, I think one of the fundamental difficulties in figuring out how to position PostgreSQL (whether using Simon's multi-model idea or Object-Relational, something else entirely, or some combination) is that PostgreSQL is an extraordinarily competent and full-featured database management system. I have a very rough draft of how I'd explain it I will send here for some feedback in terms of general message and accuracy before I look at adapting it as a patch against the docs.
However, while I was going through this and asking "how would I build something utilizing object-oriented approaches in PostgreSQL?" I realized how few of the features of this sort I was currently using. I have been using PostgreSQL since 1999, and been seriously been trying to use advanced features for six, and I realized I have barely begun to scratch the surface. It's really refreshing to look at this and realize that even after 12-13 years of becoming familiar with a piece of software, a little exercise like this provides all sorts of features that would simplify your life. The fact is that what PostgreSQL really is, inside the box, is a transactional development environment where operations occur in a relational-native way and this is largely how I am approaching it. Object-relational in terms of PostgreSQL seems to mean "relational along with a bunch of tools useful for building object interfaces." I think a lot of the multi-model features that Simon talks about can be understood in these terms as well. If I was going to coin a term to call this, I would call it a "Transactional/relational development environment." Just as you can do object-oriented programming in C, PostgreSQL lets you do this in SQL. Also in my tests, I found that inherited relations do not inherit casts. Is this intentional? Is there a reason I should be putting into the documentation? Or is it just a gotcha that should be listed as a caveat? Best Wishes, Chris Travers
