Closed simonpcouch closed 8 months ago
The current code feels like a belt and bracers type approach and I don't think it should be harmful. Have we confirmed that #142 is still an issue? Looking at the issue now, I would have thought that the introduction of odbcPreviewQuery()
would have already fixed it.
Internal ticket 98494 presents quite similarly, though I agree that I thought odbcPreviewQuery()
would have solved this. #142 may be unrelated.
Closing in favor of #769.
I'm not sure why it is that we pass
rowLimit
both toodbcPreviewQuery()
anddbGetQuery()
? Introduced in https://github.com/r-dbi/odbc/commit/111cedfe2aacb1ca4f87016814fb7d295f7dfb3f. From my understanding,odbcPreviewQuery()
should limit the number of rows returned effectively and we can leavedbGetQuery(n)
as its default value,-1
, which will be passed todbFetch()
and interpreted as "return all available rows."Closes #142, possibly; I wonder if Redshift trips up on a
dbFetch(n)
value greater than what the query actually returns. I don't have a Redshift account set up for myself but will ask the customer to test.EDIT: if this does do the trick, we could split this change off into a Redshift method so that it doesn't apply to other DBMS.