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