Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id DAA69004
	for <pgsql-interfaces@postgreSQL.org>;
	Tue, 15 Feb 2000 03:00:00 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id CAA10211;
	Tue, 15 Feb 2000 02:59:40 -0500 (EST)
To: Joel Reed <jreed@support.ddiworld.com>
cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] libpq patch for binding tuples in a result set to
	user allocated memory
In-reply-to: <20000214110532.G8823@support.ddiworld.com> 
References: <20000214095958.C8823@support.ddiworld.com>
	<18990.950543823@sss.pgh.pa.us>
	<20000214110532.G8823@support.ddiworld.com>
Comments: In-reply-to Joel Reed <jreed@support.ddiworld.com>
	message dated "Mon, 14 Feb 2000 11:05:32 -0500"
Date: Tue, 15 Feb 2000 02:59:40 -0500
Message-ID: <10208.950601580@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Joel Reed <jreed@support.ddiworld.com> writes:
Tom> In the long run we'll probably be moving to some more-modern interface
Tom> design like CORBA, which should help to address performance concerns
Tom> like these.

> how would CORBA help?

Bearing in mind that I know very little about CORBA ;-), I believe the
main way it'd help us in this particular area is that it provides
support for platform-independent transmission of binary datatypes.
For example, you send an integer, you get an integer; if byte-swapping
is needed it happens automatically and you don't have to think about it.
This'd be a big win performance-wise compared to Postgres' current
approach of converting everything to ASCII strings and then having to
convert back in client code.

Now I realize that you seemed to be concerned about programming
convenience as much as shaving cycles.  I don't know enough about CORBA
to say if it helps much in that regard; perhaps someone else can answer?

BTW, I do not intend to imply that moving Postgres to CORBA is a
foregone conclusion.  A couple of people have argued for it, but
not much has been done yet; the door is certainly still open to
other ideas.  I'm just trying to point out that a complete replacement
of libpq with some other API might be a better long-term answer than
nibbling away at the edges of the API model that libpq provides.

			regards, tom lane