Re: Would like to contribute a section to docs for 9.3. Where to start?

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