libpq-events windows gotcha - Mailing list pgsql-hackers

From Andrew Chernow
Subject libpq-events windows gotcha
Date
Msg-id 491AEABD.9060003@esilo.com
Whole thread Raw
Responses Re: libpq-events windows gotcha  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Just noticed that the last libpqtypes release was broken on windows when 
dynamically linking.  The problem is that windows has two addresses for 
functions, the import library uses a stub "ordinal" address while the 
DLL itself is using the real address; yet another m$ annoyance.  This 
breaks the PQEventProc being used as a unique lookup value.

Be aware that there is nothing wrong with the libpq-events API.  One 
just has to be very careful on windows with DLLs.

libpqtypes fixed this issue by no longer publically exposing its 
PQEventProc, didn't need to do this anyways.  libpqtypes instanceData is 
meant to be private.  Version 1.2b conatins this fix and will be online 
soon.

// this used to be a macro
int PQtypesRegister(PGconn *conn)
{  return PQregisterEventProc(conn, pqt_eventproc, "pqtypes", NULL);
}

// used to be a public function named PQtypesEventproc, now internal
int pqt_eventproc(PGEventId id, void *info, void *passThrough)

This is a big gotcha for any libpq-events implementors.  It should 
probably be documented in some fashion.  Other implementations may want 
to expose the PGEventProc so its API users can access the instanceData 
... so they can get the lookup key.  For this case, a public function 
that returns the address of the private "static not dllexport" 
PGEventProc would be required.

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: array_length()
Next
From: "Robert Haas"
Date:
Subject: Re: So what's an "empty" array anyway?