Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> 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.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
