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

On Mon, Aug 13, 2012 at 7:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Chris Travers <chris(dot)travers(at)gmail(dot)com> 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