kentkwu commented on issue #4771: URL: https://github.com/apache/arrow-adbc/issues/4771#issuecomment-6843984452
Ah yes, agreed that we should align with the #4694 convention. For discovery, listing calls as a standard collection (Curt's idea, same vendor-prefix rule) makes complete sense, so there's no need for a separate `adbc.list_calls`. Building on Curt's suggestion in #4694 of binding filters and exposing them through `GetParameterSchema`, here's a rough sketch of what invocation could look like end to end: ```c // Discover, following the #4694 convention // (the "calls" collection is hypothetical, modeled on "routines") SetOption(stmt, "adbc.metadata.collection", "calls"); ExecuteQuery(stmt, &out); // call names and descriptions (schemas via the statement below) // Invoke SetOption(stmt, "adbc.statement.call", "bigquery.iceberg_catalog.create"); GetParameterSchema(stmt, ¶ms); // the call's inputs ExecuteSchema(stmt, &result); // its output, without running it Bind(stmt, input); ExecuteQuery(stmt, &out); ``` Since #4694 covers the read side, the open part seems to be the invocation side alongside it. On the client side, this could also start as a small helper in the bindings (e.g. `conn.call(name, batch)` over the convention), so nothing needs new ABI to try it out. (Admittedly, wanting to wrap this sequence into a single call might just be my TypeScript brain talking.) Does this seem like a reasonable direction? In particular, does reusing `GetParameterSchema`/`ExecuteSchema` for a call's inputs and outputs match how you're thinking about collections? -- 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]
