On Wed, May 16, 2012 at 10:21 AM, John Townsend
<jtownsend@advancedformulas.com> wrote:
> It appears that some developers (Davart) are by-passing the standard client
> library, “libpq.dll”, and directly accessing the server using Delphi or FPC.
> I am not sure of the advantage here. All libpq.dll functions can be called
> from Delphi or FPC by simply using the following example pascal coding:
> const
>
> LIBPQ_PATH = 'C:\PG\libpq.dll'; // or wherever
>
> type
>
> PGconn = Pointer;
> PPGresult = Pointer;
>
> var
> Conn: PGconn;
> ResultSet: PPGresult;
>
>
> function PQconnectdbParams(keywords, values: PChar; expand_dbname: integer):
> PGconn; cdecl;
>
> external LIBPQ_PATH name 'PQconnectdbParams';
>
> function PQconnectdb(conninfo: PChar): PGConn; cdecl;
>
> external LIBPQ_PATH name 'PQconnectdb';
>
> function PQsetdbLogin(Host, Port, Options, Tty, Db, User, Passwd: PChar):
> PGconn; cdecl;
>
> external LIBPQ_PATH name 'PQsetdbLogin';
>
> There are translation programs like “h2pas” that will do most of the work
> for you, seeing that you may have to translate 160+ c functions.
> Nonetheless, it shouldn’t take long, and one would have a nice module,
> (unit) to use for building a PostgreSQL database application using Delphi or
> FPC. Using the module one could build components as many have done.
>
> *** So...the question: Is there a good reason why you might want to NOT use
> libpq.dll, and just directly access the server through direct function
> calls? ***
Not really. I'm skeptical that Delphi is in fact bypassing libpq.
Delphi has an abstract database connection object (TDatabase etc) that
requires a driver to run. Most of the drivers I've seen (Zeos, etc)
wrap libpq. Some client drivers, notably JDBC, do bypass libpq.
This is not 'direct function calls' but a library that implements the
postgres protocol.
I generally think it's a bad idea to bypass libpq, especially if your
client stack has good compatibility with C libraries, which
ObjectPascal does.
merlin