SQLite CVSTrac

*** 15,21 ****
  The filename is the name of the shared library or DLL.  The entrypoint
  is the name of an initialization function within the shared library.
  If the entry point is omitted, a suitable entry point name is constructed
! from the filename.
  <p>
  The following code is an example of how to build a loadable extension:
  <blockquote><pre>
--- 15,55 ----
  The filename is the name of the shared library or DLL.  The entrypoint
  is the name of an initialization function within the shared library.
  If the entry point is omitted, a suitable entry point name is constructed
! from the filename using the following rules:
! <p>
! <ul>
! <li>Convert the name to lower case
! <li>Remove the path prefix from the name
! <li>Remove the first "." and all following characters from the name
! <li>If the name begins with "lib" remove the first 3 characters
! <li>Remove all characters that are not US-ASCII alphanumerics
! or underscores
! <li>Remove any leading digits and underscores from the name
! <li>Append "_init" to the name
! </ul>
! <p>
! The entry point must be a function with the following prototype:
! <blockquote><pre>
! int EntryPoint(
!   sqlite3 *db,          /* The database connection */
!   char **pzErrMsg,      /* Write error messages here */
!   const sqlite3_api_routines *pApi  /* API methods */
! );
! </pre></blockquote>
! The db parameter is the database connection pointer returned
! from <a href="/capi3ref.html#sqlite3_open">sqlite3_open()</a>.
! The extension will likely want to pass this argument through
! to routines like
! <a href="/capi3ref.html#sqlite3_create_function">sqlite3_create_function()</a>
! and
! <a href="/capi3ref.html#sqlite3_create_collation">sqlite3_create_collation()
! </a>
! If an error occurs and pzErrMsg is not NULL, then the extension
! should use <a href="/capi3ref.html#sqlite3_mprintf">sqlite3_mprintf()</a>
! to generate an error message and store that message at *pzErrMsg.
! The pApi argument contains pointers back to all of the APIs
! in the calling library.  Extensions should reference the SQLite
! API through these pointers.
  <p>
  The following code is an example of how to build a loadable extension:
  <blockquote><pre>
***************
*** 49,55 ****
  loadable extension would probably do something more useful.
  </p>
  
! <p>Additional documentation is forthcoming...</p>
  
  <h2>Wish List</h2>
  <li>Automatic loading of extension shared libraries when a database is first opened. This would benefit SQLite users who do not use the SQLite shell program, and only use the sqlite3 shared library. An sqlite specific table in each database loaded could be consulted with a list of shared library names to load. These extension shared libraries would not have paths or file suffixes (.dll or .so). The user would be expected to set up an appropriate search path via the native OS' shared library loading mechanism (PATH, LD_LIBRARY_PATH, or equivalent). The suffix would be determined at sqlite3 compile time to be .dll, .so, or whatever is appropriate for the platform. Such a table might look like this:
--- 83,104 ----
  loadable extension would probably do something more useful.
  </p>
  
! <p>Note that the extension uses the header file "sqlite3ext.h"
! instead of "sqlite3.h".  This is an imporant difference.  Dynamically
! loaded extensions should always use "sqlite3ext.h" and statically
! linked additions to the library should use "sqlite3.h".  If you
! want your code to work as either a statically linked or a dynamically
! loaded module, the you will need to use #ifdefs to #include the
! appropriate header file.</p>
! 
! <p>The SQLITE_EXTENSION_INIT1 and SQLITE3_EXTENSION_INIT2 symbols
! are C preprocessor macros that deal with redirecting the API routines
! through the function pointers in sqlite3_api_routines structure.
! You can look at the definitions of these macros in the sqlite3ext.h
! header file to find out exactly what they do, if you are curious.
! The simplest approach is just to use them as shown above.</p>
! 
! <p><hr><p>
  
  <h2>Wish List</h2>
  <li>Automatic loading of extension shared libraries when a database is first opened. This would benefit SQLite users who do not use the SQLite shell program, and only use the sqlite3 shared library. An sqlite specific table in each database loaded could be consulted with a list of shared library names to load. These extension shared libraries would not have paths or file suffixes (.dll or .so). The user would be expected to set up an appropriate search path via the native OS' shared library loading mechanism (PATH, LD_LIBRARY_PATH, or equivalent). The suffix would be determined at sqlite3 compile time to be .dll, .so, or whatever is appropriate for the platform. Such a table might look like this:

sqlite - Loadable Extensions