Closed jangorecki closed 6 years ago
Thank you for looking at the test code. Though the if-else clause is apparently misleading, raising an error is the right behavior here. https://rstats-db.github.io/DBI/reference/dbWriteTable.html
This test was introduced when this caused a segmentation fault in a past version, if I recall correctly.
Note, try clause is not used everywhere in the tests.
The other error causing one is more explicit to check for absence of segmentation fault with the error causing operation.
Loading required package: RPostgreSQL Loading required package: DBI Error in postgresqlExecStatement(conn, statement, ...) : RS-DBI driver: (could not Retrieve the result : ERROR: operator does not exist: text = integer LINE 1: select * from tmpirisdata where "Species"=0 ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. ) NULL [1] "Removing tmpirisdata\n" PASS: reached to the end of the test code without segmentation fault
Unfortunately CRAN is not raising failure flag due to the way that tests are structured. Nevertheless the failure is there as both cases PASS and FAIL meant to be handled in tests: https://github.com/tomoakin/RPostgreSQL/blob/ed8e104e86bc0eb99a45d0790bc316f46650d0c0/RPostgreSQL/tests/dbWriteTableFailTest.R#L37-L45 while the output produces: https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/RPostgreSQL-00check.html
On success this test should produce
PASS as the return value is false\n
output. It is quite likely that author of that test wanted to usetry
call in the following way:res <- try(dbWriteTable(con, 'rockdata', rock, append=TRUE, overwrite=FALSE))
. There is at least one more case of failure which should be investigated, search CRAN log forError in postgres
.