>s2: extension-functions.c
>-------------------------
>add compilation instructions for windows
>
>q1:
>----
>I used gcc version 3.4.5 (mingw-vista special r3) to compile
>"extension-functions.c" with the following options
>
>gcc -shared -fPIC -I "c:\Programme\SQLite" -o libsqlitefunctions.so
>extension-functions.c
>(I copied sqlite3ext.h before to "c:\Programme\SQLite")
I built several Windows extensions and always use:
gcc -O2 -lm -shared xyz.c -o xyz.dll
You need sqlite3.h as well. Add -I "c:\Programme\SQLite" as required.
Don't forget to invoke sqlite3_enable_load_extension() before loading.
Since you're new to this, there is something that AFAIK is not
documented at all. Depending on your execution context, it can lead to
extreme frustration and wasted hours.
It is plain impossible to override any native SQLite function with
custom functions declared as using UTF-8 encoding: the override won't
work and return SQLITE_BUSY _if_ you are loading with SQL "select
sqlite3_load_extension(...).
Loading from the C interface will work if there are no other SQL being
processed on the same connection by the time of loading.
Loading + overriding from SQL _will_ work for functions not explicitely
declared for the UTF-8 encoding. Loading new functions works like a charm.
This may look like anectodical, but implies a series of consequences
that prove to be a delicious nightmare in practice. You compiled
application may work well (calling from C works in all cases), but you
won't be able to load the same extension in most SQLite managers from
SQL (and then provide no way to invoke loading from C). Using any
wrapper not explicitely having a special SQLite device for loading from
C is hopeless, so no JDBC, ODBC, AOD, a.s.o.
These are serious limitations that you must be aware of beforehand.
There exists "half" a workaround, but it also has drawbacks. You can
load an extension using the sqlite3_auto_extension() mecanism, even
from SQL! Of course, the extension need to be prepared for that.
Have a C function, going like that:
DLL_EXPORT int auto_load(
sqlite3 *db,
char **pzErrMsg,
const sqlite3_api_routines *pApi
){
UNUSED_PARAMETER(db);
UNUSED_PARAMETER(pzErrMsg);
UNUSED_PARAMETER(pApi);
sqlite3_auto_extension((void*)sqlite3_extension_init);
return SQLITE_OK;
}
By entering select sqlite_load_extension("mydll.dll",
"auto_load"); you can make SQLite perform the C call to
sqlite3_auto_extension() for you. This of course is an SQL statement
that must be entered using an open connection. At this point, your
real extension entry point has been remembered by SQLite and will be
used when opening any new database connection. In short, you need to
first make a dummy connection, issue your SQL loading select and then
open your real connection.
Doing so means that your extension will be loaded for _all_ new
connections, so once this is done, there is no way, in the same SQLite
session, to avoid having the extension loaded. Also having different
custom functions overriding native functions at the same time is
impossible.
Because of sacred politicorrectness self-limitation, I won't describe
here what a royal pain in the ass all of this is, with all the due
respect I owe to the SQLite team.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
