refactor(c/driver/postgresql): Use copy writer in BindStream for parameter binding

[paleolimbot]

This PR refactors the BindStream to use the COPY writer instead of its own serialization logic. This logic is the same between insertion and binding, although the API used to send it to the database is slightly different. This is a helpful consolidation of logic and means that adding type support on the Arrow or Postgresql side (or fixing bugs in the inference or serialization) is slightly easier. It also means we can bind parameters that are lists and is a workaround for inserting into a table with a schema where Postgres knows how to cast the types (but ADBC might not yet).

library(adbcdrivermanager)
library(nanoarrow)

con <- adbc_database_init(
  adbcpostgresql::adbcpostgresql(),
  uri = "postgresql://localhost:5432/postgres?user=postgres&password=password"
) |> 
  adbc_connection_init()

# Create an array with a uint32 column
df <- tibble::tibble(uint32_col = 1:5)
array <- df |> 
  nanoarrow::as_nanoarrow_array(
    schema = na_struct(list(uint32_col = na_uint32()))
  )

# Create a table with an integer column
con |> execute_adbc("DROP TABLE IF EXISTS adbc_test")
con |> execute_adbc("CREATE TABLE adbc_test (uint32_col int4)")

# This will fail (types not identical)
array |> write_adbc(con, "adbc_test", mode = "append")
#> Error in adbc_statement_execute_query(stmt): INVALID_ARGUMENT: [libpq] Failed to execute COPY statement: PGRES_FATAL_ERROR ERROR:  incorrect binary data format
#> CONTEXT:  COPY adbc_test, line 1, column uint32_col

con |> 
  execute_adbc("INSERT INTO adbc_test VALUES ($1)", bind = array)
con |> 
  read_adbc("SELECT * FROM adbc_test") |> 
  tibble::as_tibble()
#> # A tibble: 5 × 1
#>   uint32_col
#>        <int>
#> 1          1
#> 2          2
#> 3          3
#> 4          4
#> 5          5

^{Created on 2024-09-12 with reprex v2.1.1}

[paleolimbot]

The CI failure here is for Python packaging and I don't think it is related (I can't find a recent Python packaging job on main to compare):

 Starting container image quay.io/pypa/manylinux2014_x86_64:2024.09.09-0...

info: This container will host the build for cp39-manylinux_x86_64, cp310-manylinux_x86_64, cp311-manylinux_x86_64, cp312-manylinux_x86_64, cp313-manylinux_x86_64...
+ docker version -f '{{json .}}'
Traceback (most recent call last):
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 49, in main
    main_inner(global_options)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 204, in main_inner
    build_in_directory(args)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 352, in build_in_directory
    platform_module.build(options, tmp_path)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/linux.py", line 459, in build
    with OCIContainer(
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/oci_container.py", line 201, in __enter__
    _check_engine_version(self.engine)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/oci_container.py", line 121, in _check_engine_version
    raise OCIEngineTooOldError() from None
cibuildwheel.errors.OCIEngineTooOldError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/python/cp39-cp39/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/python/cp39-cp39/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 422, in <module>
    main()
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 51, in main
    message = e.args[0]
IndexError: tuple index out of range

[paleolimbot]

I can't get std::numeric_limits<int>::max() to work here even with #define NOMINMAX. It works in the Windows CI but not in the Python package build 🤷

[lidavidm]

Weird.

You can use (max)() to get around it too FWIW

[lidavidm]

The CI failure here is for Python packaging and I don't think it is related (I can't find a recent Python packaging job on main to compare):

 Starting container image quay.io/pypa/manylinux2014_x86_64:2024.09.09-0...

info: This container will host the build for cp39-manylinux_x86_64, cp310-manylinux_x86_64, cp311-manylinux_x86_64, cp312-manylinux_x86_64, cp313-manylinux_x86_64...
+ docker version -f '{{json .}}'
Traceback (most recent call last):
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 49, in main
    main_inner(global_options)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 204, in main_inner
    build_in_directory(args)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 352, in build_in_directory
    platform_module.build(options, tmp_path)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/linux.py", line 459, in build
    with OCIContainer(
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/oci_container.py", line 201, in __enter__
    _check_engine_version(self.engine)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/oci_container.py", line 121, in _check_engine_version
    raise OCIEngineTooOldError() from None
cibuildwheel.errors.OCIEngineTooOldError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/python/cp39-cp39/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/python/cp39-cp39/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 422, in <module>
    main()
  File "/opt/python/cp39-cp39/lib/python3.9/site-packages/cibuildwheel/__main__.py", line 51, in main
    message = e.args[0]
IndexError: tuple index out of range

#2163

Not sure I'll get to it anytime soon but I guess we need to stop borrowing the Arrow image (or check if there's a newer one to use)

[lidavidm]

Neat!

[paleolimbot]

Thans!

CI failures are #2176 and #2163.