Re: libpq-events windows gotcha

Tom Lane wrote:
> Andrew Chernow <ac@esilo.com> writes:
>> Just noticed that the last libpqtypes release was broken on windows when 
>> dynamically linking.  The problem is that windows has two addresses for 
>> functions, the import library uses a stub "ordinal" address while the 
>> DLL itself is using the real address; yet another m$ annoyance.  This 
>> breaks the PQEventProc being used as a unique lookup value.
>> This is a big gotcha for any libpq-events implementors.  It should 
>> probably be documented in some fashion.
> 
> Hmm.  Well, it's not too late to reconsider the use of the function
> address as a lookup key ... but what else would we use instead?
> 
>             regards, tom lane
> 
> 

Here are the options we see:

1. PQregisterEventProc returns a handle, synchronized counter 
incremented by libpq.  A small table could map handle value to proc 
address, so register always returns the same handle for a provided 
eventproc.  Only register would take an eventproc, instanceData 
functions would take this magical handle.

2. string key, has collision issues (already been ruled out)

3. have implementors return a static variable address (doesn't seem all 
that different from returning a static funcaddr)

4. what we do now, but document loudly that PGEventProc must be static.  If it can't be referenced outside the DLL
directlythen the issue 
 
can't arise.  If you need the function address for calls to 
PQinstanceData, an implementor can create a public function that returns 
their private PGEventProc address.

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/