Thread: AW: [HACKERS] Revised proposal for libpq and FE/BE protocol chang es

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>

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.