| From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
|---|---|
| To: | Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com> |
| Cc: | 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 14:49:32 |
| Message-ID: | CAMsGm5dnrs69WMq3GK8f5BEWifVh1VVs3kpY2mMCv9PeuBu==g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 5 Nov 2020 at 08:34, Euler Taveira <euler(dot)taveira(at)2ndquadrant(dot)com>
wrote:
Is the database name important for this message? You should inform which
> database you want to connect for all client tools except pg_dumpall.
> Hence, you
> already know which database has the connection problem. IMO the pg_dumpall
> message should inform the database name. My suggestion is:
>
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Seino Yuki | 2020-11-05 14:54:53 | Re: enable pg_stat_statements to track rows processed by REFRESH MATERIALIZED VIEW |
| Previous Message | Justin Pryzby | 2020-11-05 13:51:57 | Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*) |