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/