Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T2ukU-00034v-Nq for pgsql-docs@postgresql.org; Sun, 19 Aug 2012 01:56:18 +0000 Received: from mail-ob0-f174.google.com ([209.85.214.174]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T2ukQ-0001Ru-Ou for pgsql-docs@postgresql.org; Sun, 19 Aug 2012 01:56:18 +0000 Received: by obbuo13 with SMTP id uo13so7538247obb.19 for ; Sat, 18 Aug 2012 18:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=czqW+U+xVMga4yoncjqu88mfaMzxos6h4wjidwLh6LA=; b=i4aXJXMpeuKCG6CVhJmnmb9QWMcVXUR/oMcEgTl7wtI7et4HMglew2xxFC4T1JlmCO vi5Tz/frq0FH7yLtQv1Eeen0laRj5CIs3TjwAbBJzAtkHNV5lSNs3jFCsbQiEfhswrGd +qYnJSg4FVGHE9Nf2ztVC8hwSou2rLhclZ4jnYtozEgR8fggQmOfQQyoN0XU+TMYk3II rVOn2GIx4XhSzZiQ5lQYuwRv33AYfSEFjeo4HIz79BV/k8nQdvZFkf/64phM79AzxbAf kO1IUrMZYifi3iI79S+t56LibbzJVSqogy9jwTOahDllGv2WiV5MLYmRJZstOoxhgbs9 79cg== MIME-Version: 1.0 Received: by 10.60.170.109 with SMTP id al13mr7197172oec.126.1345341372935; Sat, 18 Aug 2012 18:56:12 -0700 (PDT) Received: by 10.76.135.34 with HTTP; Sat, 18 Aug 2012 18:56:12 -0700 (PDT) In-Reply-To: <1345317144.3099.49.camel@jdavis> References: <502EA39E.4040301@gmx.net> <1345317144.3099.49.camel@jdavis> Date: Sat, 18 Aug 2012 18:56:12 -0700 Message-ID: Subject: Re: Would like to contribute a section to docs for 9.3. Where to start? From: Chris Travers To: Jeff Davis Cc: Peter Eisentraut , Postgres Documentation Content-Type: multipart/alternative; boundary=bcaec54b5004a2aec204c794b2c8 X-Pg-Spam-Score: -2.7 (--) X-Archive-Number: 201208/36 X-Sequence-Number: 7429 --bcaec54b5004a2aec204c794b2c8 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 18, 2012 at 12:12 PM, Jeff Davis 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 --bcaec54b5004a2aec204c794b2c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Aug 18, 2012 at 12:12 PM, Jeff D= avis <pgsql@j-davis.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. =A0I would be interested in feedba= ck as to
> > inaccuracies or omissions. =A0I would like to get the technical s= ide 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. =A0Otherwise 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. =A0Al= so it looks like Oracle used to have a document describing "object-rel= ational" features in Oracle 10. =A0Reading through other people's = views, I think Oracle might actually be ahead of us here, but... The proble= m here is relatively complex and I am afraid if I go and re-iterate everyth= ing I will end up with another book >:-D

Not that this would be a bad thing. =A0I did find Oracl= e's somewhat short book (of 200 pages) on the subject at=A0http://docs.oracl= e.com/cd/B19306_01/appdev.102/b14260.pdf

However if I am doing a book by myself I am either goin= g to publish it or release it myself. =A0A document of that scope is a litt= le 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.
=A0
2. Describe how postgres meets that criteria in a way that's:
=A0 =A0 a. compelling to users
=A0 =A0 b. connects with OOP so the users don't feel like it's a =A0 =A0 =A0 =A0bait-and-switch or get confused by starting with the
=A0 =A0 =A0 =A0wrong 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 th= ese 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= .

=A0The way I would describe it in simple terms is that = a standard RDBMS operates on sets of tuples. =A0 An ORDBMS operates on sets= of objects. =A0Those objects may have methods, may be polymorphic, and may= be encapsulated behind interfaces. =A0As Stonebreaker said in his paper, t= his is a marriage between the set-oriented relational database and the prim= itives of object oriented programming. =A0Consequently the way to look at i= t is that you have a relational database with object oriented features whic= h 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? =A0I was thinking initially of a *brief* d= escription of what was meant so that people didn't get too confused. = =A0Maybe it would be better to save the brief description for later and wri= te a longer document first that could be incorporated into the brief docume= nt by reference? =A0Maybe a book entitled "Object-Relational Programmi= ng in PostgreSQL" since this is something I have started to delve deep= ly into for LedgerSMB. =A0Maybe by that point we can figure out whether we = are pushing Object-Relational features as a subset of a multi-model approac= h or vice versa. =A0Indeed ontologically speaking, I am not sure what the d= ifference 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 ;-). =A0This being said, of course = there may be marketing reasons to push one or the other as a primary term.<= /div>

Best wishes,
Chris Travers

=
--bcaec54b5004a2aec204c794b2c8--