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

On Sat, Aug 18, 2012 at 12:12 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:

> On Fri, 2012-08-17 at 16:03 -0400, Peter Eisentraut wrote:
> > On 8/15/12 5:33 AM, Chris Travers wrote:
> > > So here is a very rough draft. I would be interested in feedback as to
> > > inaccuracies or omissions. I would like to get the technical side
> right
> > > before going into an editorial phase.
> > >
> > > Any feedback on the technical side?
> >
> > [citation needed]
> >
> > Seriously, if we are trying to justify our use of seemingly standard
> > academic terms, we should have some references to where those are
> > defined or at least discussed. Otherwise we are just begging the
> > question: PostgreSQL is object-relational because we say so.
>
> I feel like the bar is becoming pretty high for this document. It must:
>
> 1. Settle on an accepted criteria for ORDBMS
>

Probably Mike Stonebreaker's paper can be referred to here. Also it looks
like Oracle used to have a document describing "object-relational" features
in Oracle 10. Reading through other people's views, I think Oracle might
actually be ahead of us here, but... The problem here is relatively complex
and I am afraid if I go and re-iterate everything I will end up with
another book >:-D

Not that this would be a bad thing. I did find Oracle's somewhat short
book (of 200 pages) on the subject at
http://docs.oracle.com/cd/B19306_01/appdev.102/b14260.pdf

However if I am doing a book by myself I am either going to publish it or
release it myself. A document of that scope is a little wider-range than I
would like to just hand off to the community.

I think it will be worth pointing out that Oracle is an ORDBMS as well and
is really the major non-Pg-descended ORDBMS I can find on the market today.

> 2. Describe how postgres meets that criteria in a way that's:
> a. compelling to users
> b. connects with OOP so the users don't feel like it's a
> bait-and-switch or get confused by starting with the
> wrong expectation
>
> I feel like making #1 compatible with 2(a) requires some creativity; and
> #1 might be incompatible with 2(b) entirely.
>

The more I work with this and am trying to figure out how to apply these in
my own work the more I am convinced that this does connect with OOP just,
as I said, in a way that is almost but not entirely unlike normal OOP.

The way I would describe it in simple terms is that a standard RDBMS
operates on sets of tuples. An ORDBMS operates on sets of objects. Those
objects may have methods, may be polymorphic, and may be encapsulated
behind interfaces. As Stonebreaker said in his paper, this is a marriage
between the set-oriented relational database and the primitives of object
oriented programming. Consequently the way to look at it is that you have
a relational database with object oriented features which makes this sort
of operation possible (and that is, as best as I can see, how Oracle
actually positions their product as well).

But more to the point, what do people think would be a valuable role for
this document? I was thinking initially of a *brief* description of what
was meant so that people didn't get too confused. Maybe it would be better
to save the brief description for later and write a longer document first
that could be incorporated into the brief document by reference? Maybe a
book entitled "Object-Relational Programming in PostgreSQL" since this is
something I have started to delve deeply into for LedgerSMB. Maybe by that
point we can figure out whether we are pushing Object-Relational features
as a subset of a multi-model approach or vice versa. Indeed ontologically
speaking, I am not sure what the difference between multi-model and
object-relational is since Simon seems to think that object-relational is a
subset of multi-model and I think multi-model is a feature of
object-relational ;-). This being said, of course there may be marketing
reasons to push one or the other as a primary term.

Best wishes,
Chris Travers