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

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Chris Travers <[email protected]>
To: Tom Lane <[email protected]>
Cc: Postgres Documentation <[email protected]>
Subject: Re: Would like to contribute a section to docs for 9.3. Where to start?
Date: Tue, 14 Aug 2012 19:34:50 -0700
Message-ID: <CAKt_ZfsTGatSG0zi8Yytj259aS5hAzcN09pY+t_5ChshBpGUMw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAKt_Zfui6MvFezCkgUJ3h56WLjZE4OS66+YNv6b12WdrmvORZA@mail.gmail.com>
	<[email protected]>

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

view thread (13+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Would like to contribute a section to docs for 9.3. Where to start?
  In-Reply-To: <CAKt_ZfsTGatSG0zi8Yytj259aS5hAzcN09pY+t_5ChshBpGUMw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox