Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> 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 ...
It's correct,
Andrew Chernow <[EMAIL PROTECTED]> 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 ...
regar
4. what we do now, but document loudly that PGEventProc must be static.
If it can't be referenced outside the DLL directly then the issue can't
arise. If you need the function address for calls to PQinstanceData, an
implementor can create a public function that returns their private
PGEven
Andrew Chernow <[EMAIL PROTECTED]> writes:
>> Here are the options we see:
>>
>> 1. PQregisterEventProc returns a handle, synchronized counter
>> incremented by libpq. A small table could map handle value to proc
>> address, so register always returns the same handle for a provided
>> eventpro
Tom Lane wrote:
And it's not even
clear to me that it fixes the problem: wouldn't you get two different
handles if you supplied the internal and external addresses of an
eventproc?
Both #1 and #4 suffer from this issue, internal & external register
methods. They also require the same WARNIN
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
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 t
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
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
Andrew Chernow <[EMAIL PROTECTED]> writes:
> 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 a
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 t
