On Thu, Mar 25, 2010 at 15:33, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 10:35 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> Just replacing PQexec() with PQsendQuery() is pretty straightforward, we
>>> could put that replacement in a file in port/win32. Replacing
>>> PQconnectdb() is more complicated because you need to handle connection
>>> timeout. I suggest that we only add the replacement for PQexec(), and
>>> live with the situation for PQconnectdb(), that covers 99% of the
>>> scenarios anyway.
>>
>> I'll try to replace PQexec() first, and PQconnectdb() second if I have
>> enough time.
>
> Sorry for the delay. The attached patch replaces PQexec() used by dblink
> and libpqwalreceiver with pgwin32_PQexec() which is the win32 version of
> PQexec().
>
> pgwin32_PQexec() is provided as the library 'libpqbe.dll', which is created
> only on win32. dblink.dll and libpqwalreceiver.dll refer to libpqbe.dll.
> Also libpqbe.dll refers to libpq.dll.
>
> I'm not sure if my patch is in the right way. If you notice anything,
> please feel free to comment!
Well, first of all, it would require the addition of the new target to
the msvc build system, but that's easy - I can do that for you.
More to the point, I'm not sure I like the creation of yet another DLL
to deal with this. The reason this isn't just exported from the main
backend is the same reason we created the libpqwalreceiver library I'm
sure - bt that means we already have one.
How about we just use this same source file, but compile and link it
directly into both dblink and libpqwalreceiver? That'd leave us with
one DLL less, making life easier.
The downside would be that other third-party modules who need to call
libpq wouldn't be able to access this without copying the function.
But is this really something that's useful for third party modules?
As for the code itself, don't we need a CHECK_FOR_INTERRUPTS in there
for it to be actually useful?
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/