From: Michael Robinson <robinson@public.bta.net.cn>
To: pgsql-hackers@postgresql.org
Subject: More PostgreSQL+CORBA
Date: Sat, 14 Nov 1998 01:19:49 +0800 (GMT)
Message-ID: <199811131719.BAA26341@public.bta.net.cn> (raw)
CORBA in fifty words or less:
CORBA is an architecture which specifies how to:
- define the method signatures of an object type
- obtain a reference to a object instance
- invoke a method, with parameters, on an object instance
- receive the results
- all interoperably between different programming languages, object
implementations, and platforms.
Why CORBA?
If you don't do object-oriented programming and system design, the
rationale for CORBA will be hard to understand. If you don't understand
why PostgreSQL is called an "object-relational" database (and why every
row has an OID), the rationale for PostgreSQL+CORBA will be hard to
understand.
The short version goes like this:
Think of a database table as a "typedef" of a data structure, with each
row representing a malloc'ed instance of that structure type. The
database provides for persistant storage, and concurrent data access,
but with a considerable access overhead: sending an SQL query string down
a socket, parsing the query string into an execution plan, executing
the plan, coverting the returned result set into text strings, sending
the strings down a socket, retrieving the strings from the socket, and,
finally, converting the text strings back into usable data values.
With CORBA, though, you could keep a reference (OID, pointer, etc.) to
each data structure of interest, and just call a function to read or
write data to fields in that structure. Another way to think of it
is cursors without queries. The database (PostgreSQL in our case)
continues to maintain persistence and concurrent access, and the data
is also always available for relational queries.
Which ORB?
GNOME started with Mico. Mico, apparently, makes use of C++ templates,
which caused the compiler they were using to generate bloated, wallowing
code.
GNOME then adopted ORBit, which has two wins: it's in C, and (this is
the biggy) it has provisions to shortcut parameter marshalling,
transmission, authentication, reception, and demarshalling--if the client
stub and server skeleton are in the same address space, and both stub
and skeleton permit this.
This means that, with ORBit, CORBA method calls can be almost as
efficient as normal function calls.
How to use CORBA with PostgreSQL?
There are three ways I can see this working:
1. As a simple alternative for the current FE<->BE communication protocol.
The SQL query engine continues to intermediate all transactions. This
has some benefits, but is really boring to me.
2. As an alternative to both the FE<->BE communication protocol and the
SQL query engine. In this case, programs could have efficient direct
row access, but all data transfers would still be shoved through a
socket (via the Internet Inter-Orb Protocol). This could be useful,
and mildly interesting.
3. As an alternative API to libpq that would allow, for example,
embedding a Python interpreter in the backend, with PostgreSQL tables
exposed through CORBA as native Python classes, and with high
performance via ORBit method shortcutting. This, in my opinion,
would be the most useful and interesting.
-Michael Robinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: robinson@public.bta.net.cn, pgsql-hackers@postgresql.org
Subject: Re: More PostgreSQL+CORBA
In-Reply-To: <199811131719.BAA26341@public.bta.net.cn>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox