Christian Kruse <[email protected]> writes:
> Ok, so I propose the attached patch as a fix.
No, what I meant is that the ereport caller needs to save errno, rather
than assuming that (some subset of) ereport-related subroutines will
preserve it.
In general, it's unsafe to assume that any nontrivial subroutine preserves
errno, and I don't particularly want to promise that the ereport functions
are an exception. Even if we did that, this type of coding would still
be risky. Here are some examples:
ereport(...,
foo() ? errdetail(...) : 0,
(errno == something) ? errhint(...) : 0);
If foo() clobbers errno and returns false, there is nothing that elog.c
can do to make this coding work.
ereport(...,
errmsg("%s belongs to %s",
foo(), (errno == something) ? "this" : "that"));
Again, even if every single elog.c entry point saved and restored errno,
this coding wouldn't be safe.
I don't think we should try to make the world safe for some uses of errno
within ereport logic, when there are other very similar-looking uses that
we cannot make safe. What we need is a coding rule that you don't do
that.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
