I agree with Greg, the most irksome feature of SQLite is the case sensititvity - it's one of the few things MS got right with SQLserver. I know this is more mainstream/standard SQL behaviour but it's outdated in modern SQL applications that nearly always do some kind of linguistic searching. In fact, I'd go one step further and advocate making SQLite case-insensitive as a rule. I'm waiting for the flames.......
Steve -----Original Message----- From: Greg Obleshchuk [mailto:[EMAIL PROTECTED] Sent: 11 April 2004 23:02 To: D. Richard Hipp; [EMAIL PROTECTED] Subject: Re: [sqlite] A proposal for SQLite version 3.0 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
