On Fri, Aug 30, 2013 at 10:37:47AM +0200, Pepijn Van Eeckhoudt scratched on the wall: > http://www.sqlite.org/loadext.html states that: > ...omitting the second argument for the load_extension() SQL > interface - and the extension loader logic will attempt to > figure out the entry point on its own. It will first try the > generic extension name "sqlite3_extension_init". If that does > not work, it constructs a entry point using the template > "sqlite3_X_init" where the X is replaced by the lowercase > equivalent of every ASCII character in the filename... > > The documentation for sqlite3LoadExtension on the other hand says: > The entry point is zProc. zProc may be 0 in which case a > default entry point name (sqlite3_extension_init) is used. Use > of the default name is recommended. > > AFAICT the second description matches what the code actually does. The > example extensions in ext/misc all use sqlite3_<extension_name>_init. > This avoids name clashes but makes it a little bit more cumbersome for > people to load the extensions. > > What is the recommended practice for naming the extension entry point? > Should I use sqlite3_extension_init or sqlite3_<extension_name>_init?
Although using the common name does, in theory, make it a bit easier to hand-load extensions, I've always recommended using a custom entry point, even before the extension loader enhanced to search for the "sqlite3_<name>_init()" format. The main benefit to using a common entry point is for people hand-loading modules into the sqlite3(1) command line tool. That tends to be a somewhat rare situation, and when it does happen, it tends to be done by people with a strong working knowledge of SQLite, the extension system, and whatever extension they're trying to load. It means you have to type a bit less, but it is more of a convenience thing then a end-user thing. The disadvantage of using a common entry point is much more significant (IMHO). It is pretty trivial to write a module that can be built into an SO/DLL/DYLIB and loaded dynamically, or use the same code to build the module statically directly into an SQLite library. ...*if* you use a custom entry point. If you use the generic sqlite3_extension_init() entry point, you'll quickly get into namespace issues, and it can get somewhat messy. Easier to just use a custom entry point for all your extensions. Best practices for designing extensions, including entry points are covered in some detail in chapter 9 of the book "Using SQLite". -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
