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? ***
Btw, I just compiled libpq.dll with Visual C++ 2008. The resulting
compilation (32bit) was 109 KB as opposed to 165 KB which was downloaded
(Enterprise site). I use C++ very little, so this is probably due to
compiler settings / flags, or perhaps just the use of just another compiler.
Thanks
John Townsend