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.
On the whole I vote for #4 out of these.
I attached a patch for the docs. Its documented as a NOTE to the
PGEventProc.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.269
diff -C6 -r1.269 libpq.sgml
*** doc/src/sgml/libpq.sgml 13 Nov 2008 09:45:24 -0000 1.269
--- doc/src/sgml/libpq.sgml 14 Nov 2008 12:08:07 -0000
***************
*** 5252,5263 ****
--- 5252,5275 ----
<para>
A particular event procedure can be registered only once in any
<structname>PGconn</>. This is because the address of the procedure
is used as a lookup key to identify the associated instance data.
</para>
+
+ <note>
+ <para>
+ On windows, functions can have two different addresses: one accessed
+ from outside a DLL, obtained from the import library, and another from
+ inside a DLL. For this reason, implementors should never directly
expose
+ an event procedure. If the event procedure is needed by an API user,
+ then its address should be returned by a library function; ie.
+ <literal>PGEventProc MyGetEventProc(void);</literal>. This ensures
that
+ the application and DLL are always using the same address.
+ </para>
+ </note>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2 id="libpq-events-funcs">
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers