"Jiri Hajek" <[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
> >
> > I prefer to go with (3)
>
> Yes, based on the facts I agree that (3) is the best way to go - a
> developer can decide whether to use Windows methods only, or be
> cross-platform and use ICU or anything else.
>
> However, it isn't what I mean. I suggest to publish some kind of a
> standard that database developers would use. I.e. SQLite web would
> define, that if you want to make a Unicode database that can be
> openned by other applications, you should define collation e.g. as
> 'en_AU' for Australian English. This way, if I want let users of my
> application to open DB in e.g. in some database editor, I can use this
> standard and users will be able to open it in many applications
> following the standard.
>
> So, what I propose aren't actually any changes in SQLite, but rather
> publishing something that would guide all SQLite developers.
>
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. Perhaps something like this:
CREATE TABLE sqlite_shared_libs(
architecture TEXT,
library BLOB
);
You can put DLLs or shared libraries for any custom collating
functions (also any custom SQL functions or virtual table
implementations) into this table and SQLite will load them
automatically which is starts up. This allows you to create
any non-standard database extensions you want and make them
completely portable to any database editor or other tool that
wants to access the database.
A moments reflection convinces me that this is not a good idea
as stated. But perhaps it can be the seed for a idea that will
actually work. Is there some way of adding customizations to
the database file itself, or perhaps to a separate file in a
standard place the SQLite always knows to look, so that
custom enhancements and extensions to SQLite can be accomodated
in standard tools? Worth thinking about, perhaps....
--
D. Richard Hipp <[EMAIL PROTECTED]>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
