public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Chris Travers <[email protected]>
Cc: Postgres Documentation <[email protected]>
Subject: Re: Would like to contribute a section to docs for 9.3. Where to start?
Date: Mon, 13 Aug 2012 10:41:12 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKt_Zfui6MvFezCkgUJ3h56WLjZE4OS66+YNv6b12WdrmvORZA@mail.gmail.com>
References: <CAKt_Zfui6MvFezCkgUJ3h56WLjZE4OS66+YNv6b12WdrmvORZA@mail.gmail.com>
Chris Travers <[email protected]> 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
> 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. In
particular, PG data types generally don't have any notion of "IsA"
subclass relationships, though the rowtypes of inherited tables do have
that. (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 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.
regards, tom lane
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Would like to contribute a section to docs for 9.3. Where to start?
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox