paleolimbot commented on issue #1513:
URL: https://github.com/apache/arrow-adbc/issues/1513#issuecomment-1927613405
Implementation wise, the shortest path is probably to parse the decimal text
with `from_chars()` (which I think is locale-independent). The representation
we get from COPY is also not bad to convert (it's groups of four digits from 0
to 9999); however, one would have to be careful about and test cases of
over/underflow.
For types that we don't know how to deal with we already attach the database
name as field metadata...we could do that for all types (or types like decimal
and array where we know in advance that what we return is ambiguous). As you
noted, then the client could handle that conversion as a workaround.
Interface wise, I hope there is a way we can avoid
`AdbcStatementSetOption("adbc.statement.XXX_as_XXX", 1)`. There are a lot of
options regarding how to calculate an Arrow type from a database type and it's
easy to accumulate many of these. I wish there was a
`AdbcStatementRequestSchema()` to handle the case where the client already
knows what they want (perhaps after inspecting `AdbcStatementExecuteSchema()`);
however, I don't think there's a clean way to handle that with the existing
API. It would fit nicely with things like the Python capsule protocol
(`___arrow_c_array_stream__(requested_schema=xxx)`).
--
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]
