I had the question specific to above two cases, when the database name is not provided. There is no surety of having a database name same as the user name. Then why assume the database name and try to connect to it. Is it due to legacy reason or due to some common database naming practice?
I have never named a database after a person/user ... myself or otherwise.
I suspect in the early days the user running psql was typically "postgres". Since the database "postgres" is created by default if the postgres O/S user runs psql without any arguments it will connect to existing "postgres" database.
> In my specific case the problem is just that the database 'pgadmin' is not > there, then why should it be a FATAL error. I understand that any process > aborting errors are treated FATAL. But it looks like a simple error here.
Levels or errors are clearly defined: 1. ERROR means that something was wrong, but you can still continue to work in the db connection 2. FATAL means that something wrong happened, and you can't use the connection any more as it has closed.
Since failing to open db connection prohibits you from doing any more work in the db connection (which is not there) - it's clearly FATAL and not ERROR.
In this case the database does not exist, then connecting to a non existent database does not seem a FATAL issue.
If psql had some concept of "working but disconnected" I might agree with this sentiment but since its either connected or not running not finding the database its looking for means it has "stop running" which means it is dead (i.e., FATAL)