From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Chernow <ac(at)esilo(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq-events windows gotcha |
Date: | 2008-11-14 23:00:04 |
Message-ID: | 22550.1226703604@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Chernow <ac(at)esilo(dot)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 lookup key 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>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2008-11-14 23:11:24 | Re: Column reordering in pg_dump |
Previous Message | Robert Haas | 2008-11-14 22:40:34 | Re: Updated posix fadvise patch v19 |