Re: Error message style guide, take 2 {just for ideas to kick around...}

Truthfully, PostgreSQL has good error reporting, and I won't cry if it
does not get changed at all.
I just thought another system that I like might spawn some good ideas.

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, May 16, 2003 8:26 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Error message style guide, take 2
> {just for ideas to kick around...}
>
>
> "Dann Corbit" <DCorbit@connx.com> writes:
> > ... here is the OpenVms message format described:
>
> > Messages are displayed in the following format:
> > %FACILITY-L-IDENT, message-text
>
> This is fine on its own terms, but I really don't see any
> advantage that justifies changing away from our historic
> behavior.  To take it point by
> point:
>
> FACILITY: if we are talking about a Postgres-only stderr log,
> then this would be redundant.  If we are talking about a
> syslog log, then syslog already takes responsibility for
> labeling every entry with the originating daemon; so it's
> still redundant.
>
> L (level): see ERROR/WARNING/LOG/etc.  I see no advantage in
> abbreviating this to one letter.
>
> IDENT: we do have some options here, since coded message
> idents are something we don't have and are just about to add.
>  But I think you've got a steep uphill fight to argue that we
> should adopt idents other than the SQL-spec-mandated SQLSTATE
> codes.  I've got no great love for the SQLSTATE design
> myself, but it is *standard*, and you've got to admit that
> one fixed code is about as good as any other one for
> programmatic purposes.
>
> Message text: we got that.
>
>
> > The following is a typical message:
>
> > %TYPE (1)-W- (2)OPENIN (3), error opening
> _DB0:[ROSE]STATS.FOR;(4) as
> > input  (5)
>
> As an example of good message design, this is not exactly
> compelling :-( I think I understand which part of it is a VMS
> filename, but where is any hint of exactly what failed or
> why?  Somebody's been concentrating on form to the exclusion
> of function ...
>
>             regards, tom lane
>