Confusing long option in pg_receivexlog/basebackup/dumpall

On 02.05.2013 08:43, Pavan Deolasee wrote:

Hi All,

While looking at the help message of pg_basebackup, I got a bit confused by
it. It looks something like this:

Connection options:
-d, --dbname=CONNSTR connection string

So the long option says "--dbname" which is not really what its expecting.
The same issue also applies to pg_receivexlog and pg_dumpall. I wonder if
this is a well thought out user API or just an oversight when we chose to
use "-d" to pass connection string to the command, In fact, I would have
avoided using either -d or --dbname because they are used very frequently
in other commands to mean something else.

It's deliberate, although I admit it's confusing. The manual explains it:

-d connstr
--dbname=connstr

Specifies parameters used to connect to the server, as a connection string. See Section 31.1.1 for more information.

The option is called --dbname for consistency with other client applications, but because pg_basebackup doesn't connect to any particular database in the cluster, database name in the connection string will be ignored.

In other tools too, like psql, you can pass a connection string with
-d/--dbname, which is why I thought it would be best to use the same
option for passing a connection string to pg_basebackup/pg_dumpall too.

See discussion at
/messages/by-id/512520FE.6050701@vmware.com. If you
have any better ideas, I'm all ears...

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, May 2, 2013 at 11:24 AM, Heikki Linnakangas <hlinnakangas@vmware.com

wrote:

In other tools too, like psql, you can pass a connection string with
-d/--dbname, which is why I thought it would be best to use the same option
for passing a connection string to pg_basebackup/pg_dumpall too.

Ah Ok. I was not aware that you can also pass a connection string to psql
with -d option. That way it looks consistent though still confusing.

See discussion at http://www.postgresql.org/**message-id/512520FE.6050701@
**vmware.com</messages/by-id/512520FE.6050701@vmware.com&gt;.
If you have any better ideas, I'm all ears...

No, I don't have better ideas. I was worried that it was an oversight. But
now I know it was chosen this way after a careful consideration.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee