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/