I love the idea of READONLY and ENFORCE. I would certainly make use of those in amalgamation form. What license do you put these under?
You should really publish these all somewhere, there are some great features. Good work. - John Brooks On Tue, Dec 15, 2009 at 6:26 AM, <wcl...@gfs-hofheim.de> wrote: > Hi all, > > This is a quick email just to gauge interest in a number of patches I've > created for Sqlite over the last year or so. What I want to know is > whether anyone would like me to post one or more of these patches here? I > have thought about posting to http://www.sqlite.org/contrib but since the > patches modify the source code rather than provide installable extensions, > this is not really feasible -- the patches are linked to a specific Sqlite > version and need a certain amount of maintenance to keep it current. This > is my opportunity to offer something back having had such good use out of > Sqlite! > > So, the patches are as follows... > > 1. XOR operator -- in addition to AND OR & |, this gives XOR and ^ > operators. '^' is the bitwise operator so that SELECT 5^3 gives 6. 'XOR' > is the logical operator so you can do things like SELECT ... FROM ... > WHERE <expr> XOR <expr> where the select returns where either <expr> is > true, but not both. > > 2. READONLY constraint for table columns, for example: CREATE TABLE t(i > integer, j integer readonly). This optional constraint prevents values > from being changed through an UPDATE, and in addition if the integer > primary key is given the READONLY constraint then also prevents replace > operations when using INSERT OR REPLACE or UPDATE OR REPLACE. > > 3. ENFORCE constraint for table columns, for example: CREATE TABLE t(i > enforce integer, j enforce text). This optional constraint enforces type > checking so that an entry must match the column type (i.e. integer, real, > numeric, text, blob). Note: this can be done using a CHECK constraint, > but here is done internally using some additional custom VDBE opcodes to > give greater efficiency. > > 4. Optional READONLY option for the ATTACH DATABASE command: the attached > database can then be opened "readonly" even when the main database is not. > > 5. Patch to relax restriction for VIEWs to allow them to reference tables > in attached databases. > > Shortly I hope also to have completed a patch to allow a limited form of > "stored procedures" where the sqlite_prepare function can be used to > create a VDBE program with support for loops, rudimentary support for > if/then/else style constructions and generation of output rows that can be > then executed as and when. > > If there is any interest, let me know. Plus, also say whether you'd like > the diff file against the original sources or against the amalgamation. > I'm afraid I can only do this against the current sqlite version (3.6.21) > but people are welcome to try the patch against whatever version they > like. The patches also include tests that will be included in "make > test". No guarantees that it will work however well it might work for me! > > Please be patient if you do request something, because I will need to > create the appropriate patch files! > > Cheers > Will > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
