zeljko wrote:
John Townsend 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
I'm FPC user and I use libpq.so(.dll,.dylib) via zeosl
On Mon, May 21, 2012 at 9:54 AM, John Townsend
wrote:
> On 5/21/2012 7:56 AM, Merlin Moncure wrote:
>
> On Sun, May 20, 2012 at 2:52 PM, John Townsend
> wrote:
>
> By by-passing the "dll" (or "so" on Linux) library I mean you write function
> or procedure calls to the server that is running as a
On 5/21/2012 7:56 AM, Merlin Moncure wrote:
On Sun, May 20, 2012 at 2:52 PM, John Townsend
wrote:
By by-passing the "dll" (or "so" on Linux) library I mean you write function
or procedure calls to the server that is running as a service on Windows.
You don't use the library with its 160 export
Jasen Betts writes:
> On 2012-05-16, John Townsend wrote:
>> *** 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? ***
> libpq binds you to using NUL terminated C strings, and, no doubt, o
On Sun, May 20, 2012 at 2:52 PM, John Townsend
wrote:
> By by-passing the "dll" (or "so" on Linux) library I mean you write function
> or procedure calls to the server that is running as a service on Windows.
> You don't use the library with its 160 exported functions. You connect
> directly to th
On Mon, May 21, 2012 at 9:05 PM, John Townsend
wrote:
> I downloaded PIKE. The "PostgreSQL direct network module for Pike",
> pgsql.pike (and the other modules), shows how it was done.
>
> Many thanks for the tip. I rarely step out of Delphi, so I was unaware of
> the power and versatility of Pike
In that case, yes, there are such implementations around. Martijn
mentioned a few, and I mentioned the Pike one, all of which do indeed
bypass libpq and talk directly to the server. It is, as I understand
it, an open and stable protocol, so it's no different from writing a
program that connects to
On 2012-05-16, John Townsend wrote:
> *** 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? ***
libpq binds you to using NUL terminated C strings, and, no doubt, other C
idioms. if you do it
On Mon, May 21, 2012 at 6:12 AM, John R Pierce wrote:
> On 05/20/12 12:52 PM, John Townsend wrote:
>>
>> By by-passing the "dll" (or "so" on Linux) library I mean you write
>> function or procedure calls to the server that is running as a service on
>> Windows. You don't use the library with its 1
On 05/20/12 12:52 PM, John Townsend wrote:
By by-passing the "dll" (or "so" on Linux) library I mean you write
function or procedure calls to the server that is running as a service
on Windows. You don't use the library with its 160 exported functions.
You connect directly to the server thus sa
By by-passing the "dll" (or "so" on Linux) library I mean you write
function or procedure calls to the server that is running as a service
on Windows. You don't use the library with its 160 exported functions.
You connect directly to the server thus saving one layer of protocols.
To do this, y
On Sun, May 20, 2012 at 02:51:42PM +0200, zeljko wrote:
> John Townsend 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.d
John Townsend 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
I'm FPC user and I use libpq.so(.dll,.dylib) via zeoslib.
Those w
On Wed, May 16, 2012 at 10:21 AM, John Townsend
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 De
On Thu, May 17, 2012 at 1:21 AM, John Townsend
wrote:
> *** 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? ***
I don't know what you mean by function calls, but the Pike Postgres
module dire
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 cod
Does anyone know if there is a compiled version of libpq.dll (ssl
enabled) that does not require
libintl-2.dll, libiconv-2.dll
Whoever compiled these dlls failed to include version information with
them, so it makes it a royal pain to deploy them, and it appears they
must be in the system dir
17 matches
Mail list logo
