Andrew Chernow wrote:
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.
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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
