Suggest testing the edge case behavior of 64-bit integer handling more

[MichaelChirico]

DBItest/R/spec-driver-connect.R

Lines 54 to 79 in f19fb4d

	connect_bigint_numeric = function(ctx) {
	#' - `"numeric"`: always return as `numeric`, silently round
	con <- local_connection(ctx, bigint = "numeric")
	res <- dbGetQuery(con, "SELECT 10000000000")
	expect_type(res[[1]], "double")
	expect_equal(res[[1]], 1e10)
	},
	#
	connect_bigint_character = function(ctx) {
	#' - `"character"`: always return the decimal representation as `character`
	con <- local_connection(ctx, bigint = "character")
	res <- dbGetQuery(con, "SELECT 10000000000")
	expect_type(res[[1]], "character")
	expect_equal(res[[1]], "10000000000")
	},
	#
	connect_bigint_integer64 = function(ctx) {
	#' - `"integer64"`: return as a data type that can be coerced using
	#' [as.integer()] (with warning on overflow), [as.numeric()]
	#' and [as.character()]
	con <- local_connection(ctx, bigint = "integer64")
	res <- dbGetQuery(con, "SELECT 10000000000")
	expect_warning(expect_true(is.na(as.integer(res[[1]]))))
	expect_equal(as.numeric(res[[1]]), 1e10)
	expect_equal(as.character(res[[1]]), "10000000000")
	},

It should be possible to stress-test backends' handling of 64-bit integers better.

The first thing I would look for is how they handle non-representable-as-64-bit-double integers, I.e., the large % of integers between 2^55 and 2^63 that are not exact multiples of the right powers of 2.

Next, we should try and establish a standard on how NULL and -2^63 are handled (since {bit64} reserves that as NA_integer64_).

[krlmlr]

Thanks, not sure. There is the new Arrow interface, and also ADBC, backends can implement that for the full range. In the current R world, it will necessarily have to be "best effort", one way or another.