Hi there,

You seem to be doing very much thought in this area ;-)
One idea strikes me though:
	A standard ODBC Call Level Interface exists !
Why not try to get the ideas for libpq from there ? Maybe we could even
implement those 
same functions.
A small extract:
	SQLPrepare
	SQLExecute
	SQLFetch
	SQLFreeStmt

On the discussion of the protocol, I would suggest using and looking into
	pvm3 at ftp://netlib2.cs.utk.edu/pvm3
this would open a wide area of low and high speed client server protocols
like: ipcshm, unix domain sockets, and native access to high performace
interconnects.

I use it to communicate from backend user defined functions with a neural
network 
simulator. It simplifies the communication substantially.

Andreas 

> Tom Lane wrote:
> 
> Here is a revised proposal that takes into account the discussions
> of the last few days.  Any comments?
	<snip>

Thu, 30 Apr 1998 09:43:38 +0200
Zeugswetter Andreas SARZ <Andreas.Zeugswetter@telecom.at>
AW: [HACKERS] Revised proposal for libpq and FE/BE protocol chang es
Zeugswetter Andreas SARZ <Andreas.Zeugswetter@telecom.at> writes:
> One idea strikes me though:
> 	A standard ODBC Call Level Interface exists !
> Why not try to get the ideas for libpq from there ? Maybe we could even
> implement those same functions.

Hmm.  If we wanted to completely redesign the libpq API, and thereby
break every frontend application there is, this'd be a good idea.
I wasn't looking to do that.  I figured an incremental improvement
to libpq was what was called for.

However, there's nothing stopping someone from producing a brand new
frontend library, which applications could migrate to over time.
(Or more likely, new apps would be written to the new API while old
ones stick with what works...)

			regards, tom lane

PS: Thanks for the pointer to PVM; looks interesting.

Thu, 30 Apr 1998 11:16:45 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes