Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T0wXk-0003Eq-TH for pgsql-docs@postgresql.org; Mon, 13 Aug 2012 15:27:01 +0000 Received: from mail-qc0-f174.google.com ([209.85.216.174]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T0wXh-0004YZ-A5 for pgsql-docs@postgresql.org; Mon, 13 Aug 2012 15:27:00 +0000 Received: by qcro28 with SMTP id o28so2328481qcr.19 for ; Mon, 13 Aug 2012 08:26:55 -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=kwBuC5sevqbBYHtdFVrc0w1lSE6dMX0Kc/MLhoVGG6c=; b=zl/FmviGel/NWcxjZJYTe/oPCQj7eOMDWVKg0Z8tILk3liGr5AsyemXusfW2iMyd3j RbcTQZUanDww84EJZnylKRJkYBOnMvSHxZhJsG/Ejmf6zZlgPOFnga/orQrIP5T9jgAc irlzPE81u7gbJip88lSLHPuDiBbKnPYN96g1WYQAiyO98BOJ/on2JBDjftkuqyqcbDZx hhxDhrkqWsMCbETv93rwqH36e4q2q8YDNK8UxURz8dnjH9gXHGK8pzSLmX1Qx/7NZw16 hrCxo3Ht74auebY1PCuNMbcbwcjFscxkUoLAo/K2SKkBijCk0KYjkIxeHkMMmAWTK8Dl hPBQ== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr18892306oeg.37.1344871615107; Mon, 13 Aug 2012 08:26:55 -0700 (PDT) Received: by 10.76.10.73 with HTTP; Mon, 13 Aug 2012 08:26:55 -0700 (PDT) In-Reply-To: <14943.1344868872@sss.pgh.pa.us> References: <14943.1344868872@sss.pgh.pa.us> Date: Mon, 13 Aug 2012 08:26:55 -0700 Message-ID: Subject: Re: Would like to contribute a section to docs for 9.3. Where to start? From: Chris Travers To: Tom Lane Cc: Postgres Documentation Content-Type: multipart/alternative; boundary=e89a8fb1ef18e312fb04c72752ab X-Pg-Spam-Score: -2.7 (--) X-Archive-Number: 201208/11 X-Sequence-Number: 7404 --e89a8fb1ef18e312fb04c72752ab Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 13, 2012 at 7:41 AM, Tom Lane wrote: > Chris Travers writes: > > I would like to contribute a "What is an Object Relational database?" > > section to the documentation for 9.3. Where is the best place to start > > tools and community-process-wise? > > > My thinking is that since people are often confused by this label, it > would > > be worth describing what it means, and describing in brief detail > > object-relational features in PostgreSQL. > > I think there's a discussion that has to happen before that one, which > is whether we should continue pushing that term for Postgres. It was > originally applied by the Berkeley guys, well over twenty years ago, to > code that didn't even speak the same language as now (PostQUEL vs SQL). > So it's fair to ask whether the vision of the project is still the same > as then. Simon for one thinks differently: > > http://database-explorer.blogspot.com/2012/08/postgresql-multi-model-database-server.html Agreed, and actually I came here after discussing this on -advocacy, and I recognize that there is still some controversy but everyone seems to agree that the way the term is currently used is confusing, and PostgreSQL doesn't really resemble the wikipedia article on Object-Relational databases. However, it is hard to have a discussion regarding how to position PostgreSQL if we don't have a bunch of good alternatives, so I think it would still be worth offering even if the community ultimately decides to move a different direction. And of course these are not mutually exclusive either so if nothing else we have the ability of community members to position the database in other ways. > > > > My thinking is to cover the following features briefly: > > > * Table inheritance > > * Type Extensibility > > * Tuples as Types, casting tuples to various other types. > > I think PG's type extensibility features come out of the > abstract-data-type culture more than than the object culture. That's probably worth noting. > In > particular, PG data types generally don't have any notion of "IsA" > subclass relationships, though the rowtypes of inherited tables do have > that. So I noticed. You can still do some sorts of inheritance, just like you can do object-oriented programming in C.... > (Well, I guess you could claim that a domain IsA subclass of its > base type, but SQL's domain feature is so impoverished that any object > hacker would laugh at you.) > > So really the argument for calling PG object-relational comes down to > table inheritance and the IsA relationship between tuples of inherited > tables. Which is something I think few people even use anymore ... > it definitely doesn't seem like a key selling point. > I was looking at it differently, namely that there are a bunch of features that you can use together to build O-R systems. The complex types may not support inheritance, but with casts you can get some limited polymorphism. Moreover the fact that relations are classes means that you can create casts of tuples to other types. For example: create table foo ( bar text, baz int ); -- simple union type insert into foo (bar, baz) values ('test', '1'); create function foo_to_int (foo) returns int as $$ select $1.baz $$ language sql; create cast (foo as int) with function foo_to_int(foo) as implicit; select foo + 1 as value from foo; value ------- 2 (1 row) This is a trivial example and I would probably include it only by description, but the point is that the combination of casts, functions, and tables as classes allows you to create some degree of polymorphism. For example we could take an employee table and add a name function that concatenates the first and last name together according to some logic. We could then index the output of that function for full text searching. While you can't do inheritance easily with complex types, these can still be used to create abstract interfaces and the use of explicit casts might give you something like it though you'd have a fair bit of work to implement such a system. > > > I am thinking of skipping over things that may be seen as misfeatures, > such > > as class.function syntax although this could be useful in the case of > > simulating calculated fields. > > Agreed, that's not a major feature; it's just a notational detail that > people have got varying opinions about. Heck, I have varying opinions about it and my opinion on this feature is rather fluid at any given poitn. However, I am thinking that maybe mentioning it up front would mean fewer people get taken by surprise by it. Best Wishes, Chris Travers --e89a8fb1ef18e312fb04c72752ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 13, 2012 at 7:41 AM, Tom Lan= e <tgl@sss.pgh.pa.us> wrote:
Chris Travers <chris.travers@gmail.com> writes:
> I would like to contribute a "What is an Object Relational databa= se?"
> section to the documentation for 9.3. =A0Where is the best place to st= art
> tools and community-process-wise?

> My thinking is that since people are often confused by this label, it = would
> be worth describing what it means, and describing in brief detail
> object-relational features in PostgreSQL.

I think there's a discussion that has to happen before that one, = which
is whether we should continue pushing that term for Postgres. =A0It was
originally applied by the Berkeley guys, well over twenty years ago, to
code that didn't even speak the same language as now (PostQUEL vs SQL).=
So it's fair to ask whether the vision of the project is still the same=
as then. =A0Simon for one thinks differently:
http://database-explorer.blogs= pot.com/2012/08/postgresql-multi-model-database-server.html

Agreed, and actually I came here after discussing this = on -advocacy, and I recognize that there is still some controversy but ever= yone seems to agree that the way the term is currently used is confusing, a= nd PostgreSQL doesn't really resemble the wikipedia article on Object-R= elational databases.

However, it is hard to have a discussion regarding how = to position PostgreSQL if we don't have a bunch of good alternatives, s= o I think it would still be worth offering even if the community ultimately= decides to move a different direction. =A0And of course these are not mutu= ally exclusive either so if nothing else we have the ability of community m= embers to position the database in other ways.=A0


> My thinking is to cover the following features briefly:

> =A0* Table inheritance
> =A0* Type Extensibility
> =A0* Tuples as Types, casting tuples to various other types.

I think PG's type extensibility features come out of the
abstract-data-type culture more than than the object culture.
<= div>

That's probably worth noting.
=A0
=A0In
particular, PG data types generally don't have any notion of "IsA&= quot;
subclass relationships, though the rowtypes of inherited tables do have
that. =A0

So I noticed. =A0You can still do= some sorts of inheritance, just like you can do object-oriented programmin= g in C....
=A0
(Well, I guess you could claim that a domain IsA subclass of its
base type, but SQL's domain feature is so impoverished that any object<= br> hacker would laugh at you.)

So really the argument for calling PG object-relational comes down to
table inheritance and the IsA relationship between tuples of inherited
tables. =A0Which is something I think few people even use anymore ...
it definitely doesn't seem like a key selling point.

I was looking at it differently, namely that there are a = bunch of features that you can use together to build O-R systems. =A0The co= mplex types may not support inheritance, but with casts you can get some li= mited polymorphism. =A0Moreover the fact that relations are classes means t= hat you can create casts of tuples to other types. =A0For example:

create table foo (
=A0 =A0bar text,
=A0 =A0baz int
); -- simple union type

= insert into foo (bar, baz) values ('test', '1');
=
create function foo_to_int (foo) returns int as=A0
$$ select $1.baz $$ language sql;

create c= ast (foo as int) with function foo_to_int(foo) as implicit;

=A0select foo + 1 as value from foo;

=A0value=A0
-------
=A0 =A0 =A02
(1 row)

This is a trivial example and I wo= uld probably include it only by description, but the point is that the comb= ination of casts, functions, and tables as classes allows you to create som= e degree of polymorphism. =A0For example we could take an employee table an= d add a name function that concatenates the first and last name together ac= cording to some logic. =A0We could then index the output of that function f= or full text searching.

While you can't do inheritance easily with complex = types, these can still be used to create abstract interfaces and the use of= explicit casts might give you something like it though you'd have a fa= ir bit of work to implement such a system.

> I am thinking of skipping over things that may be seen as misfeatures,= such
> as class.function syntax although this could be useful in the case of<= br> > simulating calculated fields.

Agreed, that's not a major feature; it's just a notational de= tail that
people have got varying opinions about.

Hec= k, I have varying opinions about it and my opinion on this feature is rathe= r fluid at any given poitn. =A0However, I am thinking that maybe mentioning= it up front would mean fewer people get taken by surprise by it.

Best Wishes,
Chris Travers=A0
--e89a8fb1ef18e312fb04c72752ab--