kentkwu commented on issue #4771:
URL: https://github.com/apache/arrow-adbc/issues/4771#issuecomment-6841615273
Following up on the sketch I posted on adbc-drivers/bigquery#279, here's
what it could look like at the ABI level. The idea is to give vendor-specific
operations a standard shape, so they're discoverable, maintainable, and easier
for driver authors to add. Think BigQuery's Iceberg catalog management, which
has no SQL equivalent, or HiveServer2's `is_metadata_command`.
Each operation would get a name under the driver's prefix
(`bigquery.iceberg_catalog.create`), take Arrow in and return Arrow out with
declared schemas, and be listed by a reserved `adbc.list_calls` (which also
answers @serramatutu's registry question on that thread: drivers keep their own
registry, and apps discover it at runtime).
Following Ian's incubation idea there, operations that several drivers
converge on could then be promoted into the spec.
(I put some thought into the naming, but I'm happy to change any of it if
there's better terminology.)
This could work today as a convention, with no ABI changes:
```c
AdbcStatementSetOption(&stmt, "adbc.statement.call",
"bigquery.iceberg_catalog.create", &err);
AdbcStatementBind(&stmt, &input_array, &input_schema, &err);
AdbcStatementExecuteQuery(&stmt, &output_stream, NULL, &err);
```
That said, routing these through option, bind, and execute doesn't feel very
intuitive to me. A dedicated function would make them a first-class part of the
API, and easier to document, use, and reason about:
```c
struct AdbcPayload {
void* data; // concrete type implied by `type`
const char* type; // e.g. "arrow.array_stream", "arrow.array"
void (*release)(struct AdbcPayload* self);
};
AdbcStatusCode AdbcConnectionCall(
struct AdbcConnection* connection,
const char* name, // e.g. "bigquery.iceberg_catalog.create"
struct AdbcPayload* input, // NULL if no input
struct AdbcPayload* output, // NULL if no output
struct AdbcError* error);
```
Whether that should be connection- or statement-level is an open question.
Connection-level feels more natural for these examples, but statement-level
would be closer to existing usage.
@paleolimbot proposed something similar in #1398
(`AdbcConnectionCallMethod`), so I'm curious whether the appetite for a
mechanism with a more explicit contract has changed. Is the convention enough
for now, or does a dedicated function feel worth new ABI? And are there
operations folks want to expose that wouldn't fit Arrow in and an Arrow stream
out?
--
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]
