From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | John Townsend <jtownsend(at)advancedformulas(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Libpq question |
Date: | 2012-05-21 16:14:03 |
Message-ID: | CAHyXU0zjrsJcj8At+eKrxZtQ2Hj3_S+OM1DZzdTGHYfUBX+8WQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, May 21, 2012 at 9:54 AM, John Townsend
<jtownsend(at)advancedformulas(dot)com> wrote:
> On 5/21/2012 7:56 AM, Merlin Moncure wrote:
>
> On Sun, May 20, 2012 at 2:52 PM, John Townsend
> <jtownsend(at)advancedformulas(dot)com> 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 saving one layer of protocols. To do this, you
> have to translate all the c functions you need (not just the headers or ".h"
> files) into pascal. Not a trivial task!
>
> It is possible to write functions and procedures on the server but
> they must still be invoked from the client side. Currently the only
> way to use any server side features is through the frontend/backend
> protocol. libpq is a library that handles the frontend side of the
> processing -- that's why the header is named libpq-fe.h: it's for the
> front end. You can bypass libpq but that would mean you'd have to
> write your own client side handler for the protocol -- definitely a
> non-trivial project and you'd probably end up with something worse
> than libpq unless you are an expert programmer.
>
> Therein lies the problem, - I am not an expert. I know quite a bit about
> Delphi & SQL, but that's it.
>
> But to be a good you need to know both languages very well, that is C++ and
> pascal. Translating the header files is easy, that's why most developers
> use libpq.dll or .so. One uses only about 20 or so functions - that is - for
> most projects. Translating the C++ function body (some are pretty long and
> complex) takes more knowledge, not only about C but about PostGreSQL.
But why would you want to do that? C and ObjectPascal have compatible
linkage so translating function body internals has no useful value
that I can see. You wouldn't be optimizing anything since you'd have
to write something else to replace it. There is no downside to
calling into C functions from pascal. Just use the .pas from Zeos and
move on. There's nothing to optimize here; you're looking in the
wrong place.
>> In other words, you can bypass libpq itself but not the protocol. To
>> bypass the protocol, start moving your code into server functions.
>
> Using pascal (Delphi or FPC). How would this be done? This is the ultimate
> goal.
Simple: just figure out how to group queries together so that they can
be chained on the server. Typically, client library and protocol
overhead are only significant when your application is making lots of
very simple queries. Start thinking relationally and make your
queries larger and smarter and that makes the overhead go away.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Mitchell | 2012-05-21 19:34:42 | Confusion about composite indexes |
Previous Message | Steve Crawford | 2012-05-21 16:08:01 | Re: odd intermittent query hanging issue |