Since this discussion might help the OP too, I hope it's not regarded as a thread hijack. I will create a new thread otherwise. Mr. v3meo, your thoughts?
A question about this advice: "If the layer sitting in front of SQLite doesn't expose create function then you can still do so. Load the SQLite DLL separately and use sqlite3_auto_extension to register a piece of code that is called back for each new connection that registers the UDF." The goal is to expose the UDF to the "layer sitting in front". Are you saying sqlite3_auto_extension allows me to run a program, once, that will register a piece of code that is loaded whenever ANY OTHER PROGRAM creates a connection to my database file? And that this happens *transparently* -- the other program simply creates a connection as usual, and does nothing else, and the extension is ready to be used in sql statements? The other program (the "layer sitting in front of SQLite") does not first need to invoke sqlite3_enable_load_extension? Is the entry point to the extension being written to the database by sqlite3_auto_extension? Regards Tim Romano Swarthmore PA On Sun, Jul 25, 2010 at 1:24 PM, Roger Binns <rog...@rogerbinns.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/25/2010 07:08 AM, Tim Romano wrote: > > Something that can be knocked out in a half-hour > > Nothing gets banged out in half an hour with SQLite :-) Using a string > reverse example: > > - - The code has to be hooked in various places > - - The function has to deal with the various ways strings could be passed > and > returned, especially UTF8 vs UTF16 encoding > - - The function has to make sense with things like combining diacritics > and > surrogate pairs > - - The function has to deal with bad parameters (eg passed an integer, > float > or blob to reverse) > - - The function has to deal with running out of memory > - - Documentation has to be added in several different places including > inside > the code, "core functions" in syntax pages etc > - - Various specifications have to be added as well as evidence marks in > the > code (for example look at Reading Data in > http://www.sqlite.org/fileio.html > and note the [H35010] and similar annotations and at the timelime for EV > style annotations) > - - The TCL test suite has to be updated, not just for correct behaviour > but > also verifying behaviour with all the bad inputs, running out of memory, > invalid UTF8/16 etc > - - The TH3 test suite has to be updated (C code generation based) and > verify > that it maintains 100% MC/DC test coverage > - - If this function is present in other database engines then the SQL > Logic > Test suite has to be updated and outputs compared > - - The changelog has to be updated > > The code then has to be maintained and tested for all future SQLite 3 > releases and internal changes (eg if UTF32 was added, new/changing memory > allocators). > > See http://ometer.com/features.html and especially the Linus Torvalds > posts > it links to. > > > Some application > > runtime environments are "sandboxed" and do not give the developer the > > freedom to call an external library, > > But eventually the SQLite library is used so there is some mechanism to > call > external libraries, although there may be restrictions. > > > or to add UDFs to their implementation of SQLite. > > This is a good example. If the layer sitting in front of SQLite doesn't > expose create function then you can still do so. Load the SQLite DLL > separately and use sqlite3_auto_extension to register a piece of code that > is called back for each new connection that registers the UDF. > > > Of course I understand it is not the fault of the SQLite architects or > its > > author when a runtime environment restricts what can be done with SQLite. > > And it is really the authors of those environments that should be contacted > about making their wrapping more complete and facilitating full usage of > SQLite. > > And failing that you can still implement what you need in your host > programming environment (eg a reverse function). Sure it may be a lot less > efficient or more hassle, but you choose that environment :-) > > > I'm only asking that such environments be kept in mind as one of the > > criteria when assigning a priority to a requested feature. > > You are probably not aware that the SQLite C API is designed specifically > to > be easily used by other development environments. It is an absolute joy to > wrap. (Yes there a few minor quirks, but compared to some other APIs they > are insignificant.) > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxMcyoACgkQmOOfHg372QTr4gCg0Og8C3nin0Ffui+ngnuu5eJU > CKYAni8PPX4YwIi3FV6B3WIMbMebnnvE > =L6lP > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
