Re: libpq-events windows gotcha

Andrew Chernow wrote:
> 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 directly then 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.
> 

Do you have a preference form the list above, or an another idea?  If 
not, we would probably implement #1.  Although, the simplest thing is #4 
which leaves everything as is and updates the sgml docs with a strong 
warning to implementors.

I am not sure which is best.

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