Re: OO Patch

> CREATE TABLE SHAPE( ..);
> CREATE TABLE SQUARE(x1, y1, x2, y2) INHERITS(shape);
> CREATE TABLE CIRCLE(x, y, radius) INHERITS(shape);
>
> I can't just go SELECT * FROM SHAPE and call some C++ method to display
> the shape on the screen. If I maintain an attribute in SHAPE called
> "classname" manually, then I can SELECT * FROM SHAPE, and then do a
> separate query on the subclass when I know the type - very inefficient.
> Or I can do 3 separate queries. But then I'm hosed when I add a TRIANGLE
> type.
>
> What I really want is..
>
> Result r = Query<Shape>.select("SELECT ** FROM SHAPE");
> foreach(r, item) {
> item->display();
> }
>
> Which still will work when I add a triangle. I.e. typical polymorphism
> code maintenance advantage.
>
> Which is what object databases do or an object relational mapper like
> Persistance do. Without that ability I would argue there's very limited
> point in having inheritance at all.
>

I can agree with that. As I wrote a relational mapper for Smalltalk/X
based on the libpq API I noticed the same problems, when doing mapping on
tables.

But some questions/comments about that:

a) How are the indices handled ? If I define an index on an attribute
defined in TABLE SHAPE all subclasses are also handled by this index
or do we have an index for the base table and each sub table on
this attribute ?

b) Please do not make the libpq API too compilcated ! It's a charm how
small the API is and how easy the initial connection to a psqgl
database is -- compare it against the ODBC API ....

b.1)
Despite the ODBC API I rather would like to see to enhance the idea
of result
sets supported by the libpq-API. I do not need to query each tuple
what it delivers to me. I would like to open the result, query
the structure and then handle the data. If the database returns
multiple different sets (results from different tables): ok: do it the
same way for each result set.

b.2)
There were some postings about other delivering methods to retrieve
the information from each tuple. Today we get an ASCII-representation
of the result tuple and the client has to convert it.

Some were not very happy about it, but I like it. Some were concerned
about the fact, that they have to copy the result to the information
structure within their software. When you use software systems, which
are based on garbage collection systems, then one ALMOST EVER has
to do it.

c)
I would like to see more ideas about the extension of pgsql to become
an active database. The notification systen is not enough, because
it does not return the most interesting informations.

I myself would like to see something like the VERSANT event system.

d)
Please only add basic, language independent, support for
inheritance - special features can very often better simulated by
software on the client side. The best example is the introduction
of sequences.

Marten