Re: libpq-events windows gotcha

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>

In response to

Responses

Browse pgsql-hackers by date

  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