dbConnect should give advice about argument names

[hadley]

i.e. dbname, host, username, password. We can't test for this, but we can encourage backend authors to use standard names.

Related to tidyverse/dplyr#1955

[krlmlr]

We already have some in the documentation, but we should be more assertive here.

[krlmlr]

Added the following to the specs in DBI 0.5-19:

@section Specification:
DBI recommends using the following argument names for authentication
parameters:

• user for the user name
• password for the password
• host for the host name
• port for the port number
• dbname for the name of the database on the host
  Using NULL as values should use a reasonable default, in particular a
  local connection for host = NULL. For some DBMS (e.g., PostgreSQL),
  this is different to a TCP/IP connection to localhost.

I'm torn between user and username. Both variants exist with no clear preference; the odbc package has uid, CC @jimhester.

https://www.rdocumentation.org/packages/RPostgreSQL/versions/0.4-1/topics/dbConnect-methods
https://www.rdocumentation.org/packages/RMySQL/versions/0.10.9/topics/dbConnect%2CMySQLDriver-method
https://www.rdocumentation.org/packages/RODBCDBI/versions/0.1.1/topics/dbConnect%2CODBCDriver-method
https://www.rdocumentation.org/packages/ROracle/versions/1.3-1/topics/dbConnect-methods
https://www.rdocumentation.org/packages/odbc/versions/1.0.1/topics/dbConnect%2COdbcDriver-method

[hadley]

The one possible advantage of username is that user will partial match to it (assuming it's before ...)

[jimhester]

The ODBC spec unfortunately doesn't standardise this either, I think I used uid because that was used in RODBC, presumably because SQL Server accepts uid or User ID, and the latter is cumbersome to use as an argument name.

In the odbc case partial matching to username is actually bad, if a given database expects user and the function partial matches to username it is going to be very confusing and people would have to specify the user parameter as part of the connection string argument rather than as a named argument.

[krlmlr]

The generic doesn't match anything, all matching is done by individual methods. This is only about establishing a convention, I understand that this convention might be unsuitable for odbc.?

[jimhester]

Ah I thought the proposal here was to include these as the arguments in the generic signature, if it is only the documentation then either would work.

[krlmlr]

Settling for user for now.