Re: elog() proposal

Bruce Momjian writes:

> Can't we hack it to pull out only certain elogs()?  Also, don't we have
> to translate everything?  I guess not.

I'm not sure.  Someone other than me raised this point once.  It's not so
important.  I supposed, eventually people will want to translate
everything.  Feel free to keep it as once function.

> > What I mean with "type of error" is that there's a significant difference
> > between user errors  and server-side errors:
> >
> > 1. User errors should not necessarily go into the server log, unless
> > command logging is enabled.
> >
> > 2. User errors will eventually carry additional information such as error
> > codes.  Server errors will just get one default error code.
> >
> > 3. Users should not necessarily be allowed to see the details of server
> > errors at the client side, only some generic message.
> >
> > So if we made up two separate functions each for errors and notices, we
> > could raise the awareness about this, even if initially the functionality
> > would not differ much.
>
> Seems my solution is smaller and backward compatible.

Your solution renumbers the error codes, so it's definitely not
backward-compatible.

> I don't see the value in tons of options.

Well, I do.  We don't need the separate user-side error functions
initially, but eventually we will have to have them.

So, basically, what this comes down to with respect to your patch:

1. Renumbering the error codes breaks backward compatibility *silently*.

2. CRASH doesn't seem like a good name to me.

3. I agree with adding a LOG or INFO level between DEBUG and NOTICE.

4. I don't like the alignment change.  That seems very un-computer-like.

-- 
Peter Eisentraut   peter_e@gmx.net