MIME-Version: 1.0
In-Reply-To: <14943.1344868872@sss.pgh.pa.us>
References: 
 <CAKt_Zfui6MvFezCkgUJ3h56WLjZE4OS66+YNv6b12WdrmvORZA@mail.gmail.com>
	<14943.1344868872@sss.pgh.pa.us>
Date: Tue, 14 Aug 2012 19:34:50 -0700
Message-ID: 
 <CAKt_ZfsTGatSG0zi8Yytj259aS5hAzcN09pY+t_5ChshBpGUMw@mail.gmail.com>
Subject: Re: Would like to contribute a section to docs for 9.3. Where
	to start?
From: Chris Travers <chris.travers@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Postgres Documentation <pgsql-docs@postgresql.org>
Content-Type: multipart/alternative; boundary=f46d04428e4268754704c744c519

--f46d04428e4268754704c744c519
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d04428e4268754704c744c519
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As a note here, I think one of the fundamental difficulties in figuring out=
 how to position PostgreSQL (whether using Simon&#39;s multi-model idea or =
Object-Relational, something else entirely, or some combination) is that Po=
stgreSQL is an extraordinarily competent and full-featured database managem=
ent system. =A0I have a very rough draft of how I&#39;d explain it I will s=
end here for some feedback in terms of general message and accuracy before =
I look at adapting it as a patch against the docs.<div>
<br></div><div>However, while I was going through this and asking &quot;how=
 would I build something utilizing object-oriented approaches in PostgreSQL=
?&quot; I realized how few of the features of this sort I was currently usi=
ng. =A0I have been using PostgreSQL since 1999, and been seriously been try=
ing to use advanced features for six, and I realized I have barely begun to=
 scratch the surface. =A0It&#39;s really refreshing to look at this and rea=
lize that even after 12-13 years of becoming familiar with a piece of softw=
are, a little exercise like this provides all sorts of features that would =
simplify your life.</div>
<div><br></div><div>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. =A0Obje=
ct-relational in terms of PostgreSQL seems to mean &quot;relational along w=
ith a bunch of tools useful for building object interfaces.&quot; =A0I thin=
k a lot of the multi-model features that Simon talks about can be understoo=
d in these terms as well. =A0If I was going to coin a term to call this, I =
would call it a &quot;Transactional/relational development environment.&quo=
t; =A0Just as you can do object-oriented programming in C, PostgreSQL lets =
you do this in SQL.</div>
<div><br></div><div>Also in my tests, I found that inherited relations do n=
ot inherit casts. =A0Is this intentional? =A0Is there a reason I should be =
putting into the documentation? Or is it just a gotcha that should be liste=
d as a caveat?</div>
<div><br></div><div>Best Wishes,</div><div>Chris Travers</div>

--f46d04428e4268754704c744c519--