On 6/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > So the choices seem to be: > > > > (1) Databases that corrupt if you move across platforms. > > (2) A 10MB database engine > > (3) Leave things as they are
OK. Here is a crazy idea for consideration: You know that you can create a custom collating function as a DLL or shared library and load it at runtime, right? This has been a capability since version 3.3.7. Suppose we define a special table in the database file that is designed to hold DLLs and/or shared libraries.
After thinking a bit, it occurs to me that there's a compromise for the Unicode case that might be workable. The algorithm for collation is pretty stable, it's just the locale data that's the problem. If SQLite understands the algorithm, then locale data can go into special tables in the database itself. Applications manipulating the database schema would need to have the relevant collation data on hand to fill in the database, but other apps concerned with only the data could operate without any special knowledge. This approach keeps the database internally self-consistent while avoiding platform and versioning issues. It's a thought. On 6/27/07, Joe Wilson <[EMAIL PROTECTED]> wrote:
The solution is obvious: http://en.wikipedia.org/wiki/Esperanto
:D ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
