With the initial positive response, I dived into the CORBA spec, the
ORBit source, and the PostgreSQL source. I have good news to report.
- CORBA and PostgreSQL were made for each other. The designers of the CORBA
architecture had object oriented databases (OODB) in mind as one of the
standard implementation of objects. E.g.:
"An ORB may have access to multiple Interface Repositories. This may occur because...an object implementation (such
asan OODB) prefers to provide its own type information..."
So, implementing CORBA for PostgreSQL is simply a matter of following the
very clearly designed architecture.
- CORBA is extremely modular with well-defined interfaces between components.
This means that it should be possible to write generic CORBA glue for
PostgreSQL that could work with any ORB.
- The ORBit sources appear to be LGPL'ed, which means they can be linked to
PostgreSQL without poisoning the BSD license.
I also have bad news to report.
- Most of the CORBA functionality that PostgreSQL would rely on is currently
unimplemented in ORBit.
- While CORBA provides a very disciplined interface for allowing different
object implementations (e.g. Python and PostgreSQL) to share the same address
space and execution context safely and efficiently, the PostgreSQL backend
doesn't seem ready for it. In particular, it doesn't appear to be thread
safe. It may not even be reentrant, from what I can tell. And, if a backend
process is not punctual about reading cache synchronization messages out of
the IPC queue, it appears that excessive cache invalidation would hurt
performance.
-Michael Robinson
