On Wed, Sep 02, 2009 at 05:44:38PM -0400, Shaun Seckman (Firaxis) wrote: > I'm just curious how difficult it would be to add > support for booleans in SQLite. This would most likely involve adding a > new type affinity as well as adding "true" and "false" keywords to the > lexer. There's much more that could be done but I'm just looking for > rudimentary support.
The SQL Standard does specify and OPTIONAL boolean type. > I understand that ANSI C doesn't have native support for > booleans and that's fine, ANSI C99 most certainly does have a boolean type. > I would just like to reduce some memory > overhead as well as use those keywords instead of creating integer > fields using 0 and 1. SQLite3 uses a variable length encoding for integers on disk, so you will gain no space on disk by having a native boolean type. Well, if you had a table with a single column and that column was a boolean, an RDBMS could express the entire table as a sparse bitstring indexed by row number/ID/OID, with two bits per row (two bits would be needed to encode: true, false, null/unknown, and "this record doesn't exist"). But such a thing would be a huge new feature for SQLite3, with very few uses. And you're not really going to save memory in SQLite3 by having a boolean type either -- 31 or 63 bits are a wash in the context of evaluating a prepared statement. _Your_ application could save memory by treating booleans as a single bit and packing them into bitstrings, but you can do that now without any help from SQLite3. A group_concat() like aggregation function could be defined that groups and concatenates boolean inputs into a bitstring -- this might be helpful to you. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
