Re: OO Patch - Mailing list pgsql-hackers

Marten Feldtmann wrote:

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

At the moment there is a separate index for each subclass, but this
should probably not be the default.

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

There will be 2 levels of API. An important part of an object database
is the existance of the client side cache. The lowest level API would be
something like libpq - that is uncached. Next there would be ODMG
interfaces for various languages that incorporate the client side cache.
I would say the only people who would continue to use libpq level would
be people writing higher level interfaces. ODMG is just too convenient.

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

I'm a bit vague on what you mean here. But if you go the full OO way,
the language polymorphism will do all the handling of different result
sets. The ODMG layer will do the hard work.

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

Again, using ODMG takes the hard work out of it. You stop caring about
what format the information is delivered in.

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

Oh, a Versant fan. Good, I like Versant. The only flaw in the Versant
event system is events can be lost when the receiver is dead, which may
or may not matter depending on the application.

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