Hadley Wickham
Hadley Wickham
No concrete news from us, but we are discussing this internally. I can see the appeal of creating a new core package without support for ggplot2, but our experience doing...
Can you find any documentation for how tables are supposed to be qualified in DB2? That makes it easy for me to confirm the fix in the absence of the...
@al-obrien Does it work with out the quotes? ```sql SELECT MYTABLE.* FROM MYCATALOG.MYSCHEMA.MYTABLE WHERE ("MYCOLUMN " != 'SOMEVALUE') ``` Does it work if there's an explicit alias? ```sql SELECT "MYTABLE".*...
Interesting, thanks! Does adding an alias help?
Thanks so much for the exploration!
Maybe `query()` would be better than `tbl()`? This would also reduce some of the complexity of dbplyr dplyr integration. Currently `tbl(con, name)` calls `dplyr::tbl.DBIConnection()` -> `dbplyr::tbl.src_dbi()` -> `dbplyr::tbl_sql()`.
Query feels a bit too imperative; it doesn't directly query the database but instead generates a data.frame like object that you can use with dplyr verbs. Maybe `lazy_query()`? `virtual_frame()`? `db_frame()`?...
`db_table()` doesn't feel great when you're giving it a SQL string: ```R db
From claude brainstorming ```R # Real database db_table(con, "flights") db_query(con, "SELECT * FROM flights WHERE year = 2023") # Testing con
The `db_` prefix isn't great because of the existing generics, so maybe `query_table()`, `query_sql()`, and `query_mimic()`? SQL is only 3 letters, but it's close enough that it doesn't feel far...