Обсуждение: Why separate pgenlist DLL?

Поиск
Список
Период
Сортировка

Why separate pgenlist DLL?

От
Heikki Linnakangas
Дата:
Hi,

On Windows, when the driver is built with MSDTC support, we build some
of the MSDTC functions in separate DLLs: pgenlist.dll and pgxalib.dll.
Why do we do that? Why not just link everything in the main DLL?

- Heikki


Re: Why separate pgenlist DLL?

От
"Inoue, Hiroshi"
Дата:
(2014/06/17 2:44), Heikki Linnakangas wrote:
> Hi,
>
> On Windows, when the driver is built with MSDTC support, we build some
> of the MSDTC functions in separate DLLs: pgenlist.dll and pgxalib.dll.
> Why do we do that? Why not just link everything in the main DLL?

pgxalib.dll should be a separate DLL because it is essentially irrevant
  to the drivers. It is called from MSDTC process when resolutions of
in-doubt transactions are needed. As Craig Ringer reported, the 64bit
pgxalib.dll is used on 64bit OS even when transactions are PREPAREd
via 32bit ODBC applications. Though pgxalib.dll calls ODBC APIs
currently, it's not calling driver's APIs directly and can call e.g.
libpq APIs instead.

As for pgenlist(a).dll, though I've never thought to unify it with
main DLL, there may be a room for discussion.

There were some reasons.
1. Basically for Windows only.
2. Many users don't use this functionality at all.
3. COM-style C++ programming and most part of the code is handling
    asynchronous requests for COM-like objects out of ODBC APIs.

I have been much more nervous in programming pgenlist than psqlodbc
and have felt isolating the code is preferable.

regards,
Hiroshi Inoue

--
I am using the free version of SPAMfighter.
SPAMfighter has removed 10925 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

Do you have a slow PC? Try a Free scan
http://www.spamfighter.com/SLOW-PCfighter?cid=sigen



Re: Why separate pgenlist DLL?

От
Heikki Linnakangas
Дата:
On 06/17/2014 12:07 PM, Inoue, Hiroshi wrote:
> (2014/06/17 2:44), Heikki Linnakangas wrote:
>> Hi,
>>
>> On Windows, when the driver is built with MSDTC support, we build some
>> of the MSDTC functions in separate DLLs: pgenlist.dll and pgxalib.dll.
>> Why do we do that? Why not just link everything in the main DLL?
>
> pgxalib.dll should be a separate DLL because it is essentially irrevant
>    to the drivers. It is called from MSDTC process when resolutions of
> in-doubt transactions are needed. As Craig Ringer reported, the 64bit
> pgxalib.dll is used on 64bit OS even when transactions are PREPAREd
> via 32bit ODBC applications. Though pgxalib.dll calls ODBC APIs
> currently, it's not calling driver's APIs directly and can call e.g.
> libpq APIs instead.

Oh, I see.

> As for pgenlist(a).dll, though I've never thought to unify it with
> main DLL, there may be a room for discussion.
>
> There were some reasons.
> 1. Basically for Windows only.
> 2. Many users don't use this functionality at all.
> 3. COM-style C++ programming and most part of the code is handling
>      asynchronous requests for COM-like objects out of ODBC APIs.
>
> I have been much more nervous in programming pgenlist than psqlodbc
> and have felt isolating the code is preferable.

Yeah, it makes sense to keep some distance. I think it would be OK to
merge it into the main DLL though. It would allow us to remove a fair
amount of glue code, and would simplify the build process. I propose the
attached to do that (against my winbuild branch in github, which
contains the MSBuild infrastructure changes)

- Heikki


Вложения

Re: Why separate pgenlist DLL?

От
Craig Ringer
Дата:
On 06/21/2014 07:46 PM, Heikki Linnakangas wrote:
>>>
>>
>> pgxalib.dll should be a separate DLL because it is essentially irrevant
>>    to the drivers. It is called from MSDTC process when resolutions of
>> in-doubt transactions are needed. As Craig Ringer reported, the 64bit
>> pgxalib.dll is used on 64bit OS even when transactions are PREPAREd
>> via 32bit ODBC applications. Though pgxalib.dll calls ODBC APIs
>> currently, it's not calling driver's APIs directly and can call e.g.
>> libpq APIs instead.
>
> Oh, I see.

In fact, at most it's just another ODBC client right now, albeit one
that expects to be talking to psqlODBC.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services