wjones127 commented on code in PR #428: URL: https://github.com/apache/arrow-adbc/pull/428#discussion_r1100688466
########## 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: Makes sense. This is part of why I switched to implementing the driver manager *before* the implementation modules instead of after for Rust. Though also in Rust the driver manager does the marshaling from Rust types to C types, which saves a lot of headaches. I'd bet it's the same for almost any other client language, except C. So makes me think direct linking is mostly useful for development purposes in C, and not something we expect users of the drivers to care about. What do you think of that? > we could avoid this (there would still be AdbcDriverInit, but we could say something like the user must always provide the name of the symbol, or the name of the symbol is derived from the name of the library, or something like that). Actually I think it would be very nice if we came up with a standard for deriving the Init symbol name from the library name. It could be used as a fallback if `AdbcDriverInit` isn't found. I'll create an issue for that. -- 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]
