From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jasen Betts <jasen(at)xnet(dot)co(dot)nz> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Libpq question |
Date: | 2012-05-21 14:09:51 |
Message-ID: | 14935.1337609391@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jasen Betts <jasen(at)xnet(dot)co(dot)nz> writes:
> On 2012-05-16, John Townsend <jtownsend(at)advancedformulas(dot)com> 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.
Note that bypassing libpq will not get you around that one, because the
server (and indeed the wire protocol) also use nul-terminated strings.
Generally the places where people have chosen to reimplement the
protocol from scratch are where they *couldn't* use libpq for some
reason or other; for instance the JDBC driver doesn't use libpq because
non-Java code is painful to deal with in a Java environment. I'm pretty
doubtful that it's worth anybody's trouble to reimplement just to save a
layer of function calls.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Townsend | 2012-05-21 14:54:56 | Re: Libpq question |
Previous Message | Merlin Moncure | 2012-05-21 14:08:27 | Re: Global Named Prepared Statements |