On 2014-11-26 11:53:40 -0300, Alvaro Herrera wrote:
> Stephen Frost wrote:
> > * Andres Freund (andres@2ndquadrant.com) wrote:
> > > On 2014-11-26 08:33:10 -0500, Stephen Frost wrote:
> > > > Doesn't that argument then apply to the other messages which I pointed
> > > > out in my follow-up to Andres, where the detailed info is in the hint
> > > > and the main error message is essentially 'permission denied'?
> > >
> > > A permission error on a relation is easier to understand than one
> > > for some abstract 'replication' permission.
> >
> > The more I consider this and review the error message reporting policy,
> > the more I feel that the original coding was wrong and that this change
> > *is* the correct one to make.
>
> +1. I don't care for the idea of "not moving from main error message to
> errdetail" -- the rationale seems to be that errdetail might be hidden,
> lost, or otherwise not read by the user; if that is so, why do we have
> errdetail in the first place? We might as well just move all the
> errdetails into the main message, huh?
That rationale is imo bogus. The actual error message should be helpful
and informative - only if the error would be to verbose it should go
into the detail. It's not exactly unimportant to know why something was
prohibited. It's not like this is any form of new precedent - *loads* of
errmsg() style of messages have more information than the static string.
I don't see how you read the contrary from the guidelines:
> The primary message should be short, factual, and avoid reference to
> implementation details such as specific function names. "Short" means
> "should fit on one line under normal conditions". Use a detail message
> if needed to keep the primary message short, or if you feel a need to
> mention implementation details such as the particular system call that
> failed. Both primary and detail messages should be factual. Use a hint
> message for suggestions about what to do to fix the problem, especially
> if the suggestion might not always be applicable. It's quite common
> that you'll only see the actual error message in logs and displayed
> error messages.
That seems to give credence to *my* position, not yours.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services