Re: pgbench without dbname worked differently with psql and pg_dump - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: pgbench without dbname worked differently with psql and pg_dump
Date
Msg-id CAKFQuwYgpr1ataSwg00-QV3B1pOX6wBkp4+vs0FbJbs1OWXniQ@mail.gmail.com
Whole thread Raw
In response to pgbench without dbname worked differently with psql and pg_dump  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
On Tue, Jan 21, 2025 at 6:54 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote:

IIUC createdb has the good description [1] and it can be re-used
everywhere.

As none of those programs "create" a database the wording "The default is to create a database" seems quite a poor choice to standardize on.

The wording you suggest replacing seems fine as-is.

ISTM the following is the only issue that probably needs to be addressed.  Either by fixing the apparent bug in the code or documenting the correct behavior in the pgbench docs.

# ... but pgbench cannot
$ pgbench -U postgres
pgbench: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL:  database "hayato" does not exist
pgbench: error: could not create connection for setup

Your patch 0001 doesn't really seem to do either.
"connection to default database failed" is a strictly worse error message than the existing one used unconditionally.
There probably should still be the existing "else" block in the other hunk - we do default to OS user name - but to handle -U shouldn't we just add an "else if (username) ...block before it?

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: allow trigger to get updated columns
Next
From: Peter Smith
Date:
Subject: Re: Skip collecting decoded changes of already-aborted transactions