> - the OID (SEQUENCE's) are useless (ok, I say it again and again). Give
> PostgreSQL the OID and ask PostgreSQL to return the attributes of this
> object. Perhaps even with class informations !
>
> PostgreSQL is not able to do that ! Think about this and you see
> the usage of the OID in perhaps a different way :-)
>
> Therefore: for object system you need complete other types of object
> identification numbers.
I agree, that's why I have suggested an implied super-class "Object" for
all postgresql objects. Then you could do "SELECT ** FROM object WHERE
oid=?". The ability to place an index over sub-class hierarchies (in
this case oid for all objects) would get the good performance.
> - query over a hierarchy of classes ! See the example above ! Until
> you're not able to return multiple sets you get too much garbage or
> you need to many queries or you need much more disc-space, depending
> of the way you wrap classes to tables. This feature is a CRITICAL
> one ! This may push the performance, depending how it is done.
Yep.
> - for associations (m:n) I still need additional help tables, but
> that is ok :-)
Actually, postgres can have arrays of oids which is the ODBMS way of
handling associations. Last I looked there are some contrib functions
for doing things like ...
CREATE TABLE foo( bar [] );
CREATE TABLE bar( ... etc);
SELECT bar.** from bar, foo where array_in(bar.oid, foo.bar) and
foo.oid=?". In other words, to retrieve all the objects in a list.
(forget the actual function name).
> - no support for tree structures !
AGAIN AGREE! Original postgres had a syntax "SELECT* from foo" to get a
transitive closure on a tree! Why this was removed (argh!) I can only
guess.
> - more powerful statements DDL to change the structure of a database !
Yep, important.
> - no support to inform the client about changes inthe database !
Havn't even looked at that.