Avoid redundantly prefixing PQerrorMessage for a connection failure.
authorTom Lane
Fri, 22 Jan 2021 21:52:31 +0000 (16:52 -0500)
committerTom Lane
Fri, 22 Jan 2021 21:52:31 +0000 (16:52 -0500)
commit58cd8dca3de0b3c7d378a412eca1f7289b5e4978
tree6239036fa1062c2ecb7f2ac0474d64fa44d795c0
parent7cd9765f9bd3397b8d4d0f507021ef848b6d48d2
Avoid redundantly prefixing PQerrorMessage for a connection failure.

libpq's error messages for connection failures pretty well stand on
their own, especially since commits 52a10224e/27a48e5a1.  Prefixing
them with 'could not connect to database "foo"' or the like is just
redundant, and perhaps even misleading if the specific database name
isn't relevant to the failure.  (When it is, we trust that the
backend's error message will include the DB name.)  Indeed, psql
hasn't used any such prefix in a long time.  So, make all our other
programs and documentation examples agree with psql's practice.

Discussion: https://postgr.es/m/1094524.1611266589@sss.pgh.pa.us
21 files changed:
contrib/oid2name/oid2name.c
contrib/vacuumlo/vacuumlo.c
doc/src/sgml/libpq.sgml
doc/src/sgml/lobj.sgml
src/bin/pg_dump/pg_backup_db.c
src/bin/pg_dump/pg_dumpall.c
src/bin/pg_dump/t/002_pg_dump.pl
src/bin/pg_upgrade/server.c
src/bin/pgbench/pgbench.c
src/bin/pgbench/t/001_pgbench_with_server.pl
src/bin/scripts/common.c
src/interfaces/ecpg/ecpglib/connect.c
src/interfaces/ecpg/test/expected/connect-test5.stderr
src/test/examples/testlibpq.c
src/test/examples/testlibpq2.c
src/test/examples/testlibpq3.c
src/test/examples/testlibpq4.c
src/test/examples/testlo.c
src/test/examples/testlo64.c
src/test/isolation/isolationtester.c
src/tools/findoidjoins/findoidjoins.c