Re: Would like to contribute a section to docs for 9.3. Where to start?
От | Tom Lane |
---|---|
Тема | Re: Would like to contribute a section to docs for 9.3. Where to start? |
Дата | |
Msg-id | 14943.1344868872@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Would like to contribute a section to docs for 9.3. Where to start? (Chris Travers <chris.travers@gmail.com>) |
Ответы |
Re: Would like to contribute a section to docs for 9.3. Where
to start?
Re: Would like to contribute a section to docs for 9.3. Where to start? |
Список | pgsql-docs |
Chris Travers <chris.travers@gmail.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 > 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
В списке pgsql-docs по дате отправления: