Re: proposal: additional error fields

On May 1, 2012, at 20:05, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, May 1, 2012 at 4:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I continue to maintain that the SQLSTATE is a much better basis for
>> solving this problem. Its categories are already pretty close to
>> what Peter needs: basically, IIUC, he wants to know about classes
>> 53, 58, maybe F0, and XX.
>
> This is really too mushy, IMHO. ERRCODE_TOO_MANY_CONNECTIONS isn't
> what I'd call an oh-shit condition even though it's in class 53, but
> this "could not create archive status file \"%s\"" is definitely an
> oh-shit regardless of what errcode_for_file_access() returns.
>
> Also, the fact is that most people do not log SQLSTATEs. And even if
> they did, they're not going to know to grep for 53|58|maybe F0|XX.
> What we need is an easy way for people to pick out any log entries
> that represent conditions that should never occur as a result of any
> legitimate user activity.
> Like, with grep. And, without needing to
> have a PhD in Postgresology.
>

If you want something really simple why not output all elog calls to one file and ereport calls to the current log?

If you recognize the need to fix existing code so that you can determine the severity levels you desire then go all the way and use SQLSTATE at the call level and then add meta-data about those codes higher up. That meta-data is then customizable so those who want the too many connections error can see them while those that do not can turn them off.

With the addition of the PostgreSQL specific severity category both that value and the SQLSTATE upon which it is based should be something that is considered best practice to output (and the default) and future attention should be given to ensuring that the code is as accurate as possible. Since existing log formats would still be valid upgrades should not be an issue.

David J.