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(at)gmx(dot)net