| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
| Cc: | Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: redundant error messages |
| Date: | 2020-11-05 15:53:56 |
| Message-ID: | 20201105155356.GA17113@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2020-11-05 16:01:43 | Re: libpq compression |
| Previous Message | Dmitry Dolgov | 2020-11-05 15:41:31 | Re: How to retain lesser paths at add_path()? |