The proposal for version 3.0 looks very promising and I hope all the major changes will be implemented. Most of the enhancements seem to add flexibility and scalability to to the "C" based api. This is great as at the "C" api call level you can do anything you want. But I do not see any changes to add similar flexibility at the SQL language level. Declarative programming is much more productive than writing many lines of "c" code to do any data manipulation tasks. The current SQL language implementation excels at the vast majority of data manipulation needs but falls short in being able to implement a complete data management system at the SQL language level.
One example is creating a database. SQLite can only create a database at the "c" api level. This should be changed to be able to use a CREATE DATABASE <dbname> command. The sqlite3_open function should be implemented with one major change. Instead of passing the complete file name of the database, pass in the name of the directory where the master/system database will be created/opened. Only the master/system database should be created automatically if one is not located in that directory. A sqlite3_create function as well as a CREATE DATABASE command would create a user database in the same directory as the master/system database by default as the system database would contain a list of all user database that have been created under that system database. Once a database has been created, a USE <dbname> command would open that database if it is found in the master/system database and make this the current database. The DETACH command could then delete the user database link into the master/system database and this user database would then be free to ATTACH to another master/system database. Once this functionality is implemented it should not be hard to implement a sqlite_users table in the master/system database to holder user information so the GRANT/REVOKE command could be implemented against any user database listed in the master/system database. All of the above is based on the simple command of creating a database at the SQL language level. Many other enhancements to the SQL language could/should be implemented and I would gladly make more suggestions if any other current users of SQLite feel that this would be a good step forward B.Thomas -----Original Message----- From: D. Richard Hipp [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 9:22 AM To: [EMAIL PROTECTED] 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] ------------------------------------------------------------ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. ============================================================
