Andrew Chernow <ac@esilo.com> writes:
>> 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.
Applied, but I editorialized on the wording a bit. Let me know if you
think this is wrong ...
regards, tom lane
Index: libpq.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.269
diff -c -r1.269 libpq.sgml
*** libpq.sgml 13 Nov 2008 09:45:24 -0000 1.269
--- libpq.sgml 14 Nov 2008 22:57:05 -0000
***************
*** 5255,5260 ****
--- 5255,5273 ---- <structname>PGconn</>. This is because the address of the procedure is used as a
lookupkey to identify the associated instance data. </para>
+
+ <caution>
+ <para>
+ On Windows, functions can have two different addresses: one visible
+ from outside a DLL and another visible from inside the DLL. One
+ should be careful that only one of these addresses is used with
+ <application>libpq</>'s event-procedure functions, else confusion will
+ result. The simplest rule for writing code that will work is to
+ ensure that event procedures are declared <literal>static</>. If the
+ procedure's address must be available outside its own source file,
+ expose a separate function to return the address.
+ </para>
+ </caution> </listitem> </varlistentry> </variablelist>