"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