You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that the object with class "SQL" produced by dbQuoteIdentifier(pq_conn, 'some.string') surrounds the string with " which the grep() in dbUnquoteIdentifier(pq_conn, quoted_sql) sees. But the object with class "SQL" produced by DBI::SQL(dbplyr::in_schema('some', 'string')), which his how dbplyr generates the table name to pass to DBI, does not add the ", apparently because it's coming to DBI as an identifier. The absence of the double quotes dplyr's copy_to() to blow up with an RPostgres connection, via the calls to db_copy_to() and dbExistsTable().
Since dbUnquoteIdentifier() actually wants a dot-separated schema.table pair, I'm not sure why it's so fussy about the presence of the quotes. Could we consider making them optional? The operative code appears to be the regex at line 74 of RPostgres' quote.R.
An alternative might be to teach dbplyr's IDENT class handling to add quotes, but that will have a series of knock-on effects in places that assume these objects can be pasted into SQL strings - not insoluble, but would be good to understand the benefit of dbUnquoteIdentifier()'s requirement for quotation marks as a start.
It appears that the object with class "SQL" produced by
dbQuoteIdentifier(pq_conn, 'some.string')
surrounds the string with " which the grep() indbUnquoteIdentifier(pq_conn, quoted_sql)
sees. But the object with class "SQL" produced byDBI::SQL(dbplyr::in_schema('some', 'string'))
, which his how dbplyr generates the table name to pass to DBI, does not add the ", apparently because it's coming to DBI as an identifier. The absence of the double quotes dplyr'scopy_to()
to blow up with an RPostgres connection, via the calls todb_copy_to()
anddbExistsTable()
.Since
dbUnquoteIdentifier()
actually wants a dot-separated schema.table pair, I'm not sure why it's so fussy about the presence of the quotes. Could we consider making them optional? The operative code appears to be the regex at line 74 of RPostgres' quote.R.An alternative might be to teach dbplyr's IDENT class handling to add quotes, but that will have a series of knock-on effects in places that assume these objects can be pasted into SQL strings - not insoluble, but would be good to understand the benefit of
dbUnquoteIdentifier()
's requirement for quotation marks as a start.The text was updated successfully, but these errors were encountered: