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 <[email protected]> wrote:
Pavel Stehule <[email protected]> writes:
2009/4/2 Tom Lane <[email protected]>:
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 developer responsibility.
Well, if the init function is sufficiently carefully coded to back out
just the changes it's managed to apply, then good for it. But we
still
aren't losing much by leaving dfmgr as-is.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
