RE: Re: More on elog and error codes

> So we need some good error numbering scheme. Any ideas?

I'm a newbie, but have been following dev and have a few comments
and these are thoughts not criticisms:

1) I've seen a huge mixture of "how to implement" to support some
desired feature without first knowing "all" of the features that
are desired. Examination over all of the mailings reveals some
but not all of possible features you may want to include.
2) Define what you want to have without worrying about how to do it.
3) Design something that can implement all of the features.
4) Reconsider design if there are performance issues.

e.g.

Features desired
* system
* subsystem
* function
* file, line, etc
* severity
* user-ability-to-recover
* standards conformance - e.g.. SQL std
* default msg statement
* locale msg statement lookup mech, os dep or indep (careful here)
* success/warning/failure
* semantic taxonomy
* syntactic taxonomy
* forced to user, available to api, logging or not, tracing
* concept of level
* reports filtering on some attribute
* interoperation with existing system reports e.g. syslog, event log,...
* system environment snapshot option
(e.g. resource low/empty may/should trigger a log of conn cnt,
sys resource counts, load, etc)
* non-mnemonic internal numbers (mnemonic only to obey stds and then
only as a function call, not by implementation)
* ease of use (i.e. pgsql-dev-hacker use)
* ease of use (i.e. api development use)
* ease of use (i.e. rolling into an existing system, e.g. during
transition both may need to be in use.)
* ease of use (i.e. looking through existing errors to find one
that may "correctly" fit the situation, instead of
creating yet-another-error-message.)
* ease of use (i.e. maybe having each "sub-system" having its own
"error domain" but using the same error mechanism)
* distinction btwn error report, debug report, tracing report, etc
* separate the concepts of
- report creation
- report delivery
- report reception
- report interpretation
* what do other's do, other's as in os, db, middleware, etc
along with their strong and weak points
... what else do you want... and lets flesh out the meaning of
each of these. Then we can go on to a design...

Sorry if this sounds like a lecture.

With regards to mnemonic things - ugh - this is a database.
I've worked with a LARGE electronics company that had
10 and 12 digit mnemonic part numbers. The mnemonic-ness
begins to break down. (So you have a part number of an eprom,
what is the part number when it is blown - still an eprom?
how about including the version of the sw on the eprom? is it
now an assembly? opps that tended to mean multiple parts attached
together, humm still looks like an eprom?) They have gone through
a huge transition to move away, as has the industry from mnemonic
numbers to simply an id number. You look up the id number in a
>database< :-) to find out what it is.

So why not drop the mnemonic concept and apply a function to a
blackbox dataitem to determine its attribute? But again first
determine what attributes you want, which are mandatory, optional,
system supplied (e.g. __LINE__ etc), is it for erroring, tracing,
debugging, some combo; then the appropriate dataitem can be
designed and functions defined. Functions (macros) for both the
report creation, report distribution, report reception, and
report interpretation. Some other email pointed out that
there are different people doing different things. Each of these
people-groups should identify what they need with regards to
error, debug, tracing reports. Each may have some nuances that
are not needed elsewhere, but the reporting system should be able
to support them all.

Ok, so I've got my flame suit on... but I am really trying to give
an "outsiders" birdseye view of what I've been reading, hopefully
which may be helpful.

Best regards,

.. Otto

Otto Hirr
OLAB Inc.
otto(dot)hirr(at)olabinc(dot)com
503 / 617-6595