Date: Thu, 5 Nov 2020 12:53:56 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Isaac Morland <isaac.morland@gmail.com>
Cc: Euler Taveira <euler.taveira@2ndquadrant.com>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: redundant error messages
Message-ID: <20201105155356.GA17113@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAMsGm5dnrs69WMq3GK8f5BEWifVh1VVs3kpY2mMCv9PeuBu==g@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Nov-05, Isaac Morland wrote:

> In principle, the client knows the database name. In practice, if it's
> coming from PGDATABASE or via a service configuration, one may be confused
> about the database; having the error message be explicit will avoid many
> problems. I can easily imagine that "unable to connect to database" would
> be mystifying, whereas "unable to connect to database foo" would elicit the
> response, "wait, I'm trying to connect to what now?" leading much more
> quickly to a resolution.

Also consider cases like running something via cron, where the person
reading the error output does not necessarily know what command is being
run: it might be hidden inside a script.  It's often very helpful to
have object names in error messages, even if for the normal usage it
seems that the object being operated on is very obvious by just looking
at the command.