-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
c/driver/postgresql: support falling back to non-COPY path #855
Comments
From the issue I opened before I knew about this one: This isn't critical for many applications but is annoying because it means that the ADBC driver can't be a drop-in replacement for an existing driver. Parameterized queries are a part of many existing workflows (although doesn't typically affect SQL generation tools like ibis or dbplyr, which do the preparation/inlining of parameters themselves). I have one anecdotal story of somebody who took a look at ADBC and ran across this error immediately and stopped investigating as well. library(adbcdrivermanager)
#> Warning: package 'adbcdrivermanager' was built under R version 4.3.3
con <- adbc_database_init(
adbcpostgresql::adbcpostgresql(),
uri = "postgresql://localhost:5432/postgres?user=postgres&password=password"
) |>
adbc_connection_init()
# Paramterized queries work for things like insert
write_adbc(data.frame(x = 1:5), con, "integers")
execute_adbc(con, "INSERT INTO integers VALUES ($1);", bind = data.frame(6:10))
read_adbc(con, "SELECT * from integers") |>
tibble::as_tibble()
#> # A tibble: 10 × 1
#> x
#> <int>
#> 1 1
#> 2 2
#> 3 3
#> 4 4
#> 5 5
#> 6 6
#> 7 7
#> 8 8
#> 9 9
#> 10 10
# Parameterized queries don't work for selects
read_adbc(con, "SELECT * from integers where x > $1", bind = data.frame(5L))
#> Error in adbc_statement_execute_query(stmt, stream, stream_join_parent = TRUE): NOT_IMPLEMENTED: [libpq] Prepared statements returning result sets are not implemented This unfortunately may require a separate set of infrastructure from the COPY reader and might not be able to support all types as well; however, it is probably not hard to support some basic set of types once the infrastructure is in place. |
(btw, feel free to rename this to be clearer) |
Also, fwiw, technically PQexecParams and friends allow you to request binary data, meaning we might be able to reuse some of the COPY infrastructure (I believe it is the same representation underneath). We'd just be getting row at a time instead of a bunch of rows in bulk |
Nice! I noticed that the format we were using to serialize parameters for input on the parameterized query seemed to be identical to the COPY representation as well. |
We have to support this anyways for prepared statements, might as well expose it explicitly in case you run into something where COPY BINARY breaks (see #538)
The text was updated successfully, but these errors were encountered: