Re: Frontend error logging style

I wrote:
> I'm on board with dropping the separate FATAL log level if there's
> consensus to do so; I think it adds more confusion than anything else.

I feel that the reasonable alternatives are either to drop the FATAL
log level, or try to make it actually mean something by consistently
using it for errors that are indeed fatal.  I had a go at doing the
latter, but eventually concluded that that way madness lies.  It's
not too hard to use "pg_log_fatal" when there's an exit(1) right
after it, but there are quite a lot of cases where a subroutine
reports an error and returns a failure code to its caller, whereupon
the caller exits.  Either the subroutine has to make an unwarranted
assumption about what its callers will do, or we need to make an API
change to allow the subroutine itself to exit(), or we are going to
present a user experience that is inconsistently different depending
on internal implementation details.

Just to add insult to injury, once I'd gotten done with the easy
part (use pg_log_fatal where there's an adjacent exit()), a whole
lot of TAP tests fell over, because they were expecting "error:"
not "fatal:".  The reverse direction of s/fatal/error/g only breaks
one TAP test, which says a lot about how many places are troubling
to make this distinction now.

I conclude that we ought to drop the separate FATAL level and just
use ERROR instead.

The attached revision does that, standardizes on pg_fatal() as the
abbreviation for pg_log_error() + exit(1), and invents detail/hint
features as per previous discussion.

			regards, tom lane