A design proposal for SQLite version 3.0 can be found at:<snip>
http://www.sqlite.org/prop2.html
Feedback from the user community is strongly encouraged.
Hey, this looks great!
Here are some of the things I like (correct me if any actually not present):
- New features in 3.0, 2.x maintained for bug fixes only.
- Altered "sqlite3_" API prefixes to simplify app binding to both versions.
- Principle of break everything at once (same one used with Perl 6 design).
- API backward compatability with 2.x relegated to external wrapper layer.
- Unicode is now the native text representation, and only option for files.
- All internal code from pager layer on up is natively/conceptually big-endian only, with big/little distinctions made at OS layer or other periphery.
- 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.
- Can distinguish between a NULL (explicit unknown value) and a string of zero length (explicit known value).
- Actual integers and floats which are 64 bits, when program wants *numbers*.
- Default collating output of NULLs followed by numbers, by blobs, by text.
- Ability to use binary values in indexes.
- All "unqualified" function APIs expect UTF-8 for text by default, where UTF-16 has separate functions with '16' added to their names.
- Smaller and faster than 2.x.
- Removal of deprecated callback interface.
Here are some improvements or suggestions that I can make:
- Provide support for named inspecific literal placeholders in SQL rather than only positional ones, which the "?" are. I think that some other database engines use placeholder names like ":foo" and ":bar" so you could do it that way. These are useful because the SQL code and corresponding bind function calls are a lot more self-documenting, and less prone to programmer errors (alignment errors) when making or changing longer SQL statements with lots of placeholders. Another advantage is that when the same inspecific literal value is used multiple times in the same SQL statement, as often happens, it only needs to be bound or copied by the API once. Note that for simplicity or efficiency the named and positional versions should both be available, and be mutually exclusive (eg: someone could use both at once without conflicts).
- While you are good to have support for it, I'm not sure I recognize a great amount of value that UTF-16 provides over UTF-8. More specifically, the main benefit I see UTF-16 providing is a more efficient use of disk space or memory when our data has a lot of non-latin characters in it; in that respect it tends to level the playing field resource-usage-wise for people in all parts of the world. However, 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.
- You mentioned in one line about doing something with the recent concurrency proposal discussion. Obviously this will have to be fleshed out inside the proposal before it can be commended on as feedback.
I probably forgot some of what I was going to say in this feedback, so maybe later. Note also that I am not reading anyone's responses to DRH's initial post and proposal until after I post this, so that my impressions of the original proposal are not tainted by them.
So thanks DRH, and keep up the good work.
-- Darren Duncan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
