RE: [HACKERS] More PostgreSQL+CORBA

> I started thinking about that talking to Marc about the CORBA ORB issue.
> GNOME wants ORBit, BSD'ers want mico, linux'ers want omniorb, etc...
> (forgive any possible generalizations above)
>
> Basically what I was saying to Marc is that the really ORB-dependent part
> of CORBA is the IDL-to-<language> mappings.  The logic of the CORBA object
> can be implemented as a normal object independent of the compiled stub.
> Then, all that has to be done is to fill in the stubs with code that
> acts as an adaptor to the ORB-independent object.  That way porting to
> another ORB should be trivial.

No, the IDL-to-language mappings are precisely defined by the CORBA 2.0
specification. However we do need a C to C++ thunking layer, as I said in a
previous post (that may have gotten lost in the e-mail cloud). The C++ API
as defined by CORBA 2.0 is quite different in certain areas (structs
replaced by classes, etc.)

> Someone out there correct me if I'm wrong... :)

:)

> I do like the idea of using CORBA to access postgreSQL.  There is the
> obvious advantage of not having to worry about porting libpg to every
> system and language.  CORBA ORB vendors/developers can take care
> of that.
>
> What really makes me curious is what the object's interface will be...
> Just a clone of libpg, or something more?...  I think someone earlier
> mentioned possibly doing things like directly referencing "objects."
> I think that the use of CORBA could allow for much more functionality
> than a classical SQL RDBMS interface.  I don't know that much about the
> backend, but it could be interesting to throw some ideas back and forth
> about what could be done with the interface.

The initial proof-of-concept will be a libpq wrapper. Later, we will code a
full alternate to the frontend, eventually hoping to have the FE/BE protocol
replaced with CORBA... (afaik)

> I would personally prefer to have a more natural OO interface to
> the database, possibly expanding on the idea of being able to directly
> reference objects (and hold the reference to them).

We hope to be able to export objects with a Row interface, for example,
which effectively refer to a single row in the database. That way expensive
queries of the type 'UPDATE table SET column = data WHERE pkey = value' are
avoided.

Taral