Postgres advertises "object-oriented" features which seem to include table inheritance and OIDs (eg, references to objects).
AFAIK table inheritance seems to work fine and saves you some typing in that you can modify a super class rather than all the subclasses. (I'm not sure what the performance implications are compared to the horizontal mapping approach done by MiddleKit.)
However, OIDs seem rather useless. Suppose you have a class hierarchy that includes Thing, Shape, Circle(Shape) and Rectangle(Shape). If Thing.shape were to hold an OID to a Shape, I know of no way for Postgres to return the correct shape. Instead, I believe you have to SELECT on all subclasses of Shape (in this case Circle and Rectangle) to find it. You also have to expand thoses SELECTs as new Shape subclasses are created.
Not so! Actually, PostgreSQL does exactly what you want: in PostgreSQL v7.1 and up, SELECT automatically includes all subclass tables unless the keyword ONLY is used to prevent inherited table access (see p. 145 of Bruce Momjian's book "PostgreSQL"). Since I am a PostgreSQL newbie, I did a little experiment to verify this, and found that this even applies to OID's, which (although they are "invisible" in the sense of not being returned unless specifically asked for in a SELECT) can be included in a WHERE clause just like any other attribute. Therefore, in your example above, if Thing.shape holds an OID to a Shape, you simply SELECT * from Shape WHERE OID = [Thing.shape.oid], and you'd automatically get the correct shape. (OID's are unique within a PostgreSQL database.) -- SteveWaterbury - 17 Apr 2002
This ruins the idea of object references and pointing to base classes which is something I would consider fundamental to any "object-oriented" system.
I also believe that Postgres does not provide lists and dictionaries in the same convenient matter as what OO developers (and especially Python developers) are accustomed to.
I have scanned the docs and posed this question to Postgres users but not come up with a real answer.
If you want real OO features in your database I think you either have to use a framework like MiddleKit to "fake it" in the RDBMS or use a bona fide OODB such as ZODB.
(Note that even if the OO features turn out to be fairly useless, that makes Postgres no worse than any other SQL database. eg, I wouldn't suggest that someone refrain from Postgres given the issues I raise.)
See also: MiddleKit, PostgreSQL, DatabaseIntegration
-- ChuckEsterbrook - 31 Dec 2001
I think the OO features in PostgreSQL aren't quite "there" yet. There is a discussion about this here and more.
I think the use of any RDBMS-specific feature (e.g., PostgreSQL's OO, if it actually worked well) might not be a good idea since it would effectively tie something like MiddleKit to the RDBMS.
-- EdmundLian 31 Dec 2001
No, MiddleKit uses specific classes for the different types of databases, eg, MySQLObjectStore, MSSQLObjectStore, etc. which all inherit from SQLObjectStore (which has most of what is needed). Each specific class is free to take advantage of proprietary features to optimize the underlying schema while still keeping the Python API the same.
Although, these specific classes could also provide proprietary features. Of course, if a user takes advantage of them, then yes, they would be tied to the RDBMS. But I think that should be their choice in the same way Python allows you to write platform specific or independent code as you see fit.
-- ChuckEsterbrook - 31 Dec 2001
MiddleKit uses specific classes for the different types of databases, eg, MySQLObjectStore, MSSQLObjectStore, etc.
Oh yes, I forgot about this... I was thinking of the OpenACS situation, where there a different level of abstraction used.
-- EdmundLian - 31 Dec 2001
I don't think there's any concensus on what OO features in a database should look like -- unlike relational calculous, there isn't a formalism for OO -- there isn't even anything close to concensus about what OO is or what it should look like in programming languages, and databases are a step removed.
Dictionaries and lists are really fundamental parts of the database -- each table is a dictionary, and rows themselves are sometimes referred to as "tuples" -- vaguely list like, though the table is more often used for a list (though I always find ordering rows to be awkward). Providing them as types in the database would be a classic non-normal feature (though convenient at times). In the cases when the type is opaque and it's not necessary for the database to understand the list/dictionary, you can generally find a way -- Pickle, multiple columns, SET type, etc.
-- IanBicking - 08 Mar 2002