Here are some of the things I like (correct me if any actually not present):
Your summary looks very good. Thanks you.
- SQL strings given to prepare() can have "?" placeholders for inspecific literals to fill in later with bind() functions. VERY VALUABLE.
- Actual blobs can be stored and fetched without any nasty encoding/decoding.
Version 2.8.13 already supports this, BTW. Version 3.0 will continue the support.
- Can distinguish between a NULL (explicit unknown value) and a string of zero length (explicit known value).
SQLite has had this property going back to version 1.0. The distinction is lost in the wrappers to many scripting languages. But that isn't really SQLite's fault.
I do not see UTF-16 providing any speed benefits in regards to
being 'the same' as internal Unicode representations for various operating systems like Windows or Mac OS X; true, it may match some OSs, but for others you will need just as much work or speed penalty to convert from UTF-16 to what the operating system uses and from UTF-8. Of course, you may already know this and the disk/memory usage leveling may be the main reason you support UTF-16.
The internal representation of text can be either UTF-8 or UTF-16 (either byte order). The text representation is fixed when the database is created. If you are dealing primarily with UTF-8 text, it makes sense then to create the database so that it uses UTF-8 internally. Similarly, create databases to use UTF-16 internally if that is your primary usage. That way conversions are minimized. Regardless of the internal representation, text can always be accessed as either UTF-8 or UTF-16. If what you want does not match the internal representation, an automatic conversion occurs.
-- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
