lidavidm commented on code in PR #428: URL: https://github.com/apache/arrow-adbc/pull/428#discussion_r1105185225
########## adbc.h: ########## @@ -1183,7 +1204,11 @@ AdbcStatusCode AdbcStatementExecutePartitions(struct AdbcStatement* statement, /// driver. /// /// Although drivers may choose any name for this function, the -/// recommended name is "AdbcDriverInit". +/// recommended name is "AdbcDriverInit". If you use the recommended +/// name, then driver managers will be able to automatically find +/// the entrypoint function. Drivers may also expose the same function +/// under a unique symbol so that multiple drivers can be statically +/// linked into a single binary without any conflicts. Review Comment: I've debated the same thing with myself. I expect it'll come down to the specific realities of the implementation. Java is necessarily and unfortunately somewhat of an island (JNI bindings are somewhere in that list of things to do in the back of my head). C/Go/Rust (should) interop quite well and IMO it would be a win if we could build most/all drivers in Go/Rust and provide bindings to them for C/C++, provided we can solve packaging/distribution issues. There are specific benefits I'm seeking: - Go/Rust make it easier to build heavily threaded code and/or deal with networking; even if Go is technically at a disadvantage vs C/C++, making it easier to get 90% of the way is better than struggling to get 70% of the way. - Go/Rust are aimed more at building self contained binaries, which is maybe a tradeoff, but after dealing with C++ Protobuf packaging issues I think it would be worth examining that tradeoff. That said, C/C++ are going to have easy access to libraries (libpq) and have a good amount of infrastructure set up (the validation suite, Googlebench + eventual Conbench, etc.). (But if we were to ditch libpq in favor of handrolling the client, then I would prefer Rust or Go, for instance, and we can always run the validation suite or C++ benchmark harness against Go or Rust.) -- 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]
