Re: [HACKERS] More PostgreSQL+CORBA - Mailing list pgsql-hackers

Michael Robinson <robinson@public.bta.net.cn> writes:
> [ pithy summary of CORBA snipped --- thanks, Michael! ]

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

I agree, that's not too exciting ... although replacing our current ad-hoc
FE/BE protocol with a standards-based protocol (I assume CORBA has a
recognized standard for the wire-level protocol?) might well be worth doing.

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

Actually, I find that one Extremely Useful and indeed Fascinating ;-).
In the applications I'm currently using, a large fraction of the
update queries act on single rows and have the formUPDATE table SET field(s) WHERE oid = 123456;
The overhead of doing this is horrendous, of course.  Being able to
access individual rows as if they were CORBA objects would be a lovely
performance improvement, I suspect.

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

I'm leery of this, not only because of the implementation problems other
people have mentioned (bringing the backend to a state where it is
thread-safe would be a large effort), but because it subverts all the
protection and security reasons for having the Postgres frontend/backend
architecture in the first place.  The *last* thing I'd want is client
code executing in the same process as the database server.

However, if I understand things correctly, the CORBA interface will hide
whether client code is in the same process as the backend server or not;
so we could each assemble the parts in the way we prefer.  At least, I
could build my separate-processes setup right away, and we could work
towards making the backend thread-safe so you could build your
installation your way.

Does CORBA have any provision for saying "this object is not thread
safe, don't send it concurrent operations"?  If there's something along
that line, then maybe we don't have to fix the backend before it can
live in a common address space with the client...
        regards, tom lane