Re: Would like to contribute a section to docs for 9.3. Where to start?
| От | Chris Travers |
|---|---|
| Тема | Re: Would like to contribute a section to docs for 9.3. Where to start? |
| Дата | |
| Msg-id | CAKt_ZfvLSp+vWOmYtdF01FYbEJ5hyzfpa5B=cMAy3y53tq5LDQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Would like to contribute a section to docs for 9.3. Where to start? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-docs |
On Mon, Aug 13, 2012 at 7:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Chris Travers <chris.travers@gmail.com> writes:I think there's a discussion that has to happen before that one, which
> 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.
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.
I think PG's type extensibility features come out of the
> My thinking is to cover the following features briefly:
> * Table inheritance
> * Type Extensibility
> * Tuples as Types, casting tuples to various other types.
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.
Agreed, that's not a major feature; it's just a notational detail that
> 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.
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
В списке pgsql-docs по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: Would like to contribute a section to docs for 9.3. Where to start?
Следующее
От: Jeff DavisДата:
Сообщение: Re: Would like to contribute a section to docs for 9.3. Where to start?