Re: Re: [HACKERS] Postgresql OO Patch

> the tree. If you do a "SELECT * FROM supertable*" (for example, if you were to
> redefine table* to mean select heterogeneous rows), what row will you get for a
> row that exists in a leaf? The same row is in all tables between supertable
> and the leaf. I suppose it would be necessary to have the query check each row
> and see how far down the tree it goes, or the system keeps track of that and
> returns the row-type from the table that inserted it. OR, there could be some
> extra specifier like "SELECT * FROM supertable DIGGING TO LEVEL 3". In this
> case, it would only look down into the tree to 3 levels below supertable and
> you'd never get row-types that are down lower than level 3. Anyhow, I still
> don't think returning multple row-types is going to happen, not that I have any
> authority one way or the other! :-)
>
> --
> Robert B. Easter
> reaster(at)comptechnews(dot)com
>

Your example is a very good example, that shows, why multiple result
sets are needed to get a very good object-oriented system !

Everyone here on this lists should think about: "What do we expect
from on object-oriented extension and how can it help me to improve my
system".

As an example: My software background is Smalltalk and relational-
and object-oriented databases. Now I use relational databases and from
this technology I use only a small part to do my mapping.

After reading all the postings here on the lists I looked at my
wrapper and asked myself: how would it benefit from an oo-extension.

And the result was pretty much frustrated:

- 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.

- 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.

- for associations (m:n) I still need additional help tables, but
that is ok :-)

- no support for tree structures !

- more powerful statements DDL to change the structure of a database !

- no support to inform the client about changes inthe database !

And that's it ! All the other stuff mentioned here are syntactical
sugar for people doing object-oriented database queries over pgsql
or hoping to structure their work - but I do not see, that it's
a real win.

Very frustrating !

Marten Feldtmann