Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 07c179a

Browse files
committed
Document a gotcha that happens on Windows when using libpq's new event
procedure support: it's possible to get confused because exported procedures have two different addresses. Per Andrew Chernow.
1 parent 772eedb commit 07c179a

File tree

1 file changed

+14
-1
lines changed

1 file changed

+14
-1
lines changed

doc/src/sgml/libpq.sgml

+14-1
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.269 2008/11/13 09:45:24 mha Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.270 2008/11/14 22:58:51 tgl Exp $ -->
22

33
<chapter id="libpq">
44
<title><application>libpq</application> - C Library</title>
@@ -5255,6 +5255,19 @@ int eventproc(PGEventId evtId, void *evtInfo, void *passThrough)
52555255
<structname>PGconn</>. This is because the address of the procedure
52565256
is used as a lookup key to identify the associated instance data.
52575257
</para>
5258+
5259+
<caution>
5260+
<para>
5261+
On Windows, functions can have two different addresses: one visible
5262+
from outside a DLL and another visible from inside the DLL. One
5263+
should be careful that only one of these addresses is used with
5264+
<application>libpq</>'s event-procedure functions, else confusion will
5265+
result. The simplest rule for writing code that will work is to
5266+
ensure that event procedures are declared <literal>static</>. If the
5267+
procedure's address must be available outside its own source file,
5268+
expose a separate function to return the address.
5269+
</para>
5270+
</caution>
52585271
</listitem>
52595272
</varlistentry>
52605273
</variablelist>

0 commit comments

Comments
 (0)