Hello,
I just read the proposed changes and they seem fine. A couple of thing.
The data types I think are great but can we have a large and small integer? I noticed
some people (embedded systems people) complain about this. I quite happy with the
large type but as integers will now be stored as the native type that will double the
storage requirement for numbers (64-bit integer taking 8bytes where 32 take 4bytes)
So may be something like
if the value is a number then check to see if it fits in a 32bit integer if it does
use that otherwise use a 64 bit. If this is too much trouble in code then maybe a
compile directive to use a certain size integer.
When using a INTEGER PRIMARY KEY perhaps we could use
INTEGER SMALL PRIMARY KEY
and
INTEGER LARGE PRIMARY KEY
Support for user definable collating. I'm assuming that this will give us the ability
to turn SQLite into a non case sensitive system by defining our own collation which is
not case sensitive? Which is great and you state that there will be two predefined
collations
COLLATE TEXT and COLLATE NUMERIC. Can I suggest that you create a third pre-defined
collation (to make it easy on us that want it) can you create a COLLATE TEXT_CI .
Which would be a case in-sensitive collation. Then the people that really want this
can use it off the bad, as it were. I'm sure it will be a lot easier for you to
create it that for someone else.
API and preferred way of executing queries
I'm assuming there will still be the wrapper to execute a SQL in one line .
You state that there may or may not be the call-back function wrapper. I would be an
advocate for keeping it. This way of handling returned data is most useful.
Sometimes when returning thousands or more rows of data you want to cancel the
statement without a call-back function you must wait until the statement is finished
and then discard the result. Having a call-back allows you (or the user) to terminate
the statement.
Apart from that great changes , more complete but things change and grow (which is
good). If I had to decide which is my most wanted feature from the stuff above I
would say COLLATE TEXT_CI as this would enable me to use = instead of LIKE in my
lookups (I really don't like case sensitive data in the real world)
kind regards
Greg O
----- Original Message -----
From: D. Richard Hipp
To: [EMAIL PROTECTED]
Sent: Wednesday, April 07, 2004 11:22 PM
Subject: [sqlite] A proposal for SQLite version 3.0
A design proposal for SQLite version 3.0 can be found at:
http://www.sqlite.org/prop2.html
Feedback from the user community is strongly encouraged.
An executive summary of the proposed changes follows:
* Support for UTF-16
* Better BLOB support
* User-defined collating sequences (for better
internationalization support)
* Smaller and faster than 2.8.13.
The plan is to continue to support the 2.8.X series
indefinately and in parallel to the 3.X series. But
the only changes to 2.8.X going forward will be bug
fixes. New features will go into 3.X. Beta releases
of version 3.X are expected within a few months.
I do not have much experience with UTF-16 and am
expecially interested in feedback on that area of
the design.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
