Greg Stark writes:
> Hmm. One case where this logic might not be true would be if the dll
> relies on c++ style static initializers and destructors. In that case
> it may very well leave hooks in place in case of an error and only
> clean them up when you call dlclose().
Interesting point,
Pavel Stehule writes:
> Maybe an safe minimum is cleaning symbols table without closing
> library. Then the code from lib will be accessible, but functionality
> will be disabled (for Postgres)?
If the library doesn't get added to the list in dfmgr.c, we'll never
look for symbols within it anyway
2009/4/2 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/2 Tom Lane :
>>> So I'm thinking this is really unnecessary and we should leave well
>>> enough alone.
>
>> I see it. I thing , an safety of this exception should be solved only
>> by programmer. It's important to release all hooks, and then ra
Hmm. One case where this logic might not be true would be if the dll
relies on c++ style static initializers and destructors. In that case
it may very well leave hooks in place in case of an error and only
clean them up when you call dlclose().
--
Greg
On 1 Apr 2009, at 22:58, Tom Lane
Pavel Stehule writes:
> 2009/4/2 Tom Lane :
>> So I'm thinking this is really unnecessary and we should leave well
>> enough alone.
> I see it. I thing , an safety of this exception should be solved only
> by programmer. It's important to release all hooks, and then raise an
> exception. It is in
2009/4/2 Tom Lane :
> Pavel Stehule writes:
>> attached patch allows raising exception from _PG_init function as was
>> discussed before.
>
> I fooled around with this and came up with the attached improved
> version, which allows reporting the full error status. However,
> after thinking some mo
Pavel Stehule writes:
> attached patch allows raising exception from _PG_init function as was
> discussed before.
I fooled around with this and came up with the attached improved
version, which allows reporting the full error status. However,
after thinking some more I feel that this is probably
Hello
attached patch allows raising exception from _PG_init function as was
discussed before.
regards
Pavel Stehule
*** ./src/backend/utils/fmgr/dfmgr.c.orig 2009-03-31 20:32:21.0 +0200
--- ./src/backend/utils/fmgr/dfmgr.c 2009-03-31 21:59:36.0 +0200
***
*** 281,287 **
