Think about dbListFields() vs. dbColumnInfo()

[krlmlr]

The latter provides more information, but requires a result set. Currently, dplyr seems to require it, too (r-dbi/RMySQL#130 (comment)).

I'd vote for including it again, perhaps with a default implementation that forwards to colnames(dbGetQuery(..., n = 0)) (#76).

[krlmlr]

• Soft-deprecate dbListFields()
• Add dbColumnInfo(Connection, character) to obtain column info for a table
• Add default implementation for dbListFields() that forwards to dbColumnInfo(Connection)

[russellpierce]

In working on this please keep an eye on what happens with the Postgres drivers. Neither the old RPostgreSQL or the new RPostgres seem to have methods for dbColumnInfo at the moment.

[krlmlr]

Postponed to a later release.

[krlmlr]

We can't add dbColumnInfo(Connection, character) because that would require altering the interface of the generic, and cause havoc downstream.

[russellpierce]

@krlmlr So, what is the plan then? I'm sorry I'm not following

[krlmlr]

Something else then, perhaps a new generic altogether -- dbGetColumnInfo()? Another option would be a Table class that encapsulates a DBIConnection and a name, so that this can be passed to dbColumnInfo() as one piece. A third option would be to pass the table name as part of ... and not declare it in the interface.

?

[russellpierce]

Passing as ... seems reasonable at first blush. What's the downside?

[krlmlr]

I don't particularly like the name of dbColumnInfo(), it's a noun. I'm still not sure if this alone warrants the definition of a new generic, given that dbColumnInfo() seems to be implemented by several backends already.

I'm also not sure if we should prefer two different generics, one for tables given by name, the other for result sets. What would these be called?

[russellpierce]

YMMV, but a verbed noun is sometimes challenging is it fetch, get, retrieve, load, etc? That dbColumnInfo works with existing backends does seem to recommend it. dbResultInfo? /shrug