Thread: errmsg("... because ...")

Hackers,

There are a bunch of error messages saying something like

"cannot foo because bar"

For example,

errmsg("cannot assign to field \"%s\" of column \"%s\" because its type %s is not a composite type")

What do you think of changing those to use errdetail in addition to
errmsg?  So this particular example would become something like

errmsg("cannot assign to field \"%s\" of column \"%s\"),
errdetail("Its type %s is not a composite type.")


There are some of them that should probably be left alone, like

errmsg("terminating connection because of crash of another server process")

I see around a dozen messages in the backend that could be changed like
this.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La gente vulgar solo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> There are a bunch of error messages saying something like
> "cannot foo because bar"

> What do you think of changing those to use errdetail in addition to
> errmsg?

I'm dubious that this is really an improvement...

In any case we are past string freeze for 8.0, so it would be something
to consider for later.
        regards, tom lane

Alvaro Herrera wrote:
> errmsg("cannot assign to field \"%s\" of column \"%s\" because its
> type %s is not a composite type")
>
> What do you think of changing those to use errdetail in addition to
> errmsg?  So this particular example would become something like
>
> errmsg("cannot assign to field \"%s\" of column \"%s\"),
> errdetail("Its type %s is not a composite type.")

The style guidelines state that an error message should include the 
reason for the error.  That is fully intentional, and I would consider 
the above to be a step backward.

In fact, every use of %m would fall into your bunch as well.  We only 
write "could not open file: %m" instead of "could not open file because 
%m" for grammatical reasons.  I don't think splitting out the %m would 
be an improvement.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/