Small. Fast. Reliable.
Choose any three.

This information is obsolete. You are looking at the CVSTrac source management system display for SQLite that was replaced by Fossil on 2009-08-11. The information shown here has not been updated since that cut-over. These pages are retained for historical reference only.

A place to request SQLite features.

  • Not sure if you entertain extensions to SQL Syntax, but a LIKE() operator that worked like IN(v1, v2, v3, ...) would be a convenience, i.e. as you can say WHERE x IN (val1,val2,val3 ...) you could say WHERE x LIKE('val1%','val2%','val3%', ...), in other words, an implicit OR'ing of the values without having to specify the operator or repeat the column-name in the statement. [I am writing a specialized full-text search app for ancient languages where spelling hadn't been normalized yet and reflected regional dialect pronunciations, and so there are sometimes dozens of ways to spell the same word; this LIKE(v1,v2,v3) feature would make building queries a lot easier and streamline the syntax.]

  • UserDefinedFunctions: Create User Defined Functions in SQLite.

  • sqlite3_step_back: A function that when called, will receive a sqlite3_statement and will act like an inverse sqlite3_step. Providing a way to go back and forward in the prepared sql statement and the resulting rows. Please send comments to croscato@hotmail.com. See ScrollingCursor for remarks on why this feature is unlikely to ever be implemented.

  • There should be a way to check the progress of a long running sqlite3_get_table() call. Please send comments to dreizehntanz[at]web.de

  • Implement a function strfmt() with behavior of printf or something like it

  • A version of SQLite.dll that can be registered in WinPE v2 (Vista)

  • Implement a transparent cryptographic usage

  • Enable multiple threads to use the same sqlite memory database without doing the synchronization

  • Enable multiple processes to use the same sqlite memory database. Using a ramdisk for this is cumbersome and slower than the direct (:memory:) way.

  • Dumping to, and restoring from disk an sqlite memory database

  • Attaching to an sqlite memory database image (for example one fetched from the network).

  • The sqlite3 command line util uses stdin to execute scripts, which works when using the command line. I'd also like to request a command line argument (like -source or -file or -i) so when my program wants to spawn sqlite3 it can specify a file without having to spawn bash/cmd to do the redirection. Doesn't .read work for you?

  • for the .schema output add blank lines between the output of each table to improve readability of large tables.

  • the .import command, should ignore the first line if the .header is ON.

  • Enhance sqlite3 command line processing to support pipes. In particular, "select * from table; | less".

  • Implement the RETURNING clause for insert and update operations, it's a quite usefull enhancement and will easy some data manipulation with sqlite at the same time it'll make it more compatible with postgresql and probably others.

  • ISO weeknum: extend strftime function formats analogous to the extension in the Linux 'date' command to include %g %G %V
    • %g last two digits of year of ISO week number (see %G)
    • %G year of ISO week number (see %V); normally useful only with %V
    • %V ISO week number, with Monday as first day of week (01..53)

  • Allow multiple values on an INSERT statement i.e. INSERT INTO table VALUES(...),(...),(...) to insert 3 rows.
  • Support for standard SQL SCHEMA's e.g. CREATE SCHEMA, DROP SCHEMA, ALTER SCHEMA (increased standard and postgresql compatibility).

  • Implement a "INSERT ... ON DUPLICATE INDEX ..." function as MySQL have. This has the advantage that you can do other things if you make a INSERT and the index is yet in the table (usually an UPDATE of the data) in an only one query, so the table is runned only one time instead of the two in the traditional way (INSERT -> exception -> UPDATE). Have a look at INSERT OR REPLACE (in INSERT help) or ON CONFLICT which shows alternatives to REPLACE.

  • Implement a "ITEXT" data type ("I" stand for international) which could be stored in a hidden sub-table with a language locale key linked to the main table where the field is declared. Very userful for localization of an application if combined with the locale of the machine.