iremcaginyurtturk opened a new pull request, #4625: URL: https://github.com/apache/arrow-adbc/pull/4625
`rows.Next` returned `array.String.Value` (and `LargeString`/`Binary`/`LargeBinary`) directly to `database/sql`. Those are zero-copy values aliasing the Arrow data buffer. `database/sql` retains the `driver.Value`s after `Next` returns — and after the underlying record batch is released. For ADBC results the batch's buffers are C-owned, so once the batch is released the value reads back as garbage. Minimal reproduction: reading a `VARCHAR` from a DuckDB ADBC query via this `sqldriver` returns a corrupted string (e.g. `"\xb6|:u\x14\x7f\x00"` — a stale pointer) instead of the actual text. Reading the same result directly at the Arrow level (before release) is correct, which localizes the problem to `rows.Next` handing back an alias rather than an owned value. This copies string/binary values into Go-owned memory (`strings.Clone` / `bytes.Clone`) so they outlive the record batch. The zero-copy return predates this, but it was surfaced by the recent arrow-go v18.7 bump, which changed buffer-release timing enough to make the latent aliasing fatal. Added `TestRowsStringValuesAreOwnedCopies`, which drives `rows.Next`, clobbers the source Arrow buffer, and asserts the returned value is unaffected. It fails without the fix and passes with it, and needs no external driver. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
