Automatically escape table names in DBI interface

[detule]

This is a solution to the the issue reported in #591

In particular, add an exact boolean argument to odbcConnectionTables and odbcConnectionColumns. Users should set this to TRUE to express that any non-null identifier arguments are to be matched exactly. This may lead to performance improvements for some backends.

However, this should be considered to be optionally implemented, and only as a way to reap any performance benefits from matching exactly, rather than allowing pattern value arguments.

[hadley]

I think my only remaining question is if we want to use exact = TRUE (or maybe escape = TRUE or pattern = FALSE) or I(). The advantage of an argument is that it makes it quite clear in the function signature; the advantage of I() is that it keeps the two concerns very closely coupled.

[detule]

Good question:

Can go either way on this one, but maybe slightly in favor of the argument because the user may be interacting with the API by passing in a DBI::Id or DBI::SQL argument.

Haven't thought too hard about how to pass the I() through those containers / feels like there is a way but it might start to stretch the proposition.

[hadley]

I think it would be better to call this escapePattern() and hard code it to escape % and _.

[detule]

Hey Hadley:

Renamed it - but I am not sold on escaping "%". It seems to me that it is so infrequently used as an identifier that if someone is passing "%" sign they are trying to use a wild card ( but may have forgotten to wrap the input appropriately ).

I keep thinking, should we escape the percent character in odbcConnectionColumns(conn, catalog_name = "my_cat", schema_name = "my_sch", name = "my_tbl", column_name = "%", exact = TRUE)?

Anyway, I can be moved here just let me know.

[hadley]

My feeling is that we want to make the leaky abstraction on top of the ODBC API clear, so there are two choices, either a pattern match (the default) or a literal string.

I think what you're recognising in the API is that it's a bit weird to have one parameter that controls whether or not three other arguments are escaped. That's one advantage of the interface that uses I(), but that would mean making escape = TRUE the default, which I know you're not keen on.

So only escaping _ seems like a pragmatic choice and I'm fine with it if you want to revert back to your original idea.

[detule]

Hey - thanks for continuing to think about this - good points about pros/cons. I am still thinking about how the user would pass I() through the DBI::Id container.

  > str(DBI::Id(name=I("abc"))@name)
   Named chr "abc"
   - attr(*, "names")= chr "name"

In the meantime - I think by escaping the identifiers in the DBI API endpoints we've covered most (all?) of the performance gains to be had. Copy your note on let's merge and then iterate as needed.

[detule]

Re-based. Will merge when checks are complete.

[fh-mthomson]

This is a game changer for being able to actually write to Snowflake! Thank you @detule @fh-afrachioni @hadley!