daveg wrote:
On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
A more graceful solution would be to print something to stderr and then
exit.
stderr doesn't exist, or point to a useful place, in many environments.
And a forced exit() is no better than a crash for most purposes.
I don't think libpq should core dump an app by choice.
The case that we are talking about is a bug, or would be a bug if it
could happen (the fact that we've gotten along happily with no similar
test in the existing code shows that it can't). Many forms of bug can
result in core dumps; it's foolish to try to prevent them all. And
bloating one line of code into five or more lines to defend against
can't-happen cases is a good way to end up with unreadable,
unmaintainable software.
regards, tom lane
+1
-dg
okay.
BTW, my real interest here is the libpq hooks patch requires a
lock/unlock for every conn-create, conn-destroy, result-create,
result-destroy. Currently, it looks like only the ssl stuff uses
mutexes. Adding more mutex use is a good case for a more optimized
approach on windows.
andrew
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
