SQLite Forum


7 forum posts by user ronaaron

17:09 Reply: Request: stored functions/procedures (artifact: 7f61c2ff4e user: ronaaron)

Fair enough. I do already do that in 8th: you can write extensions which call into 8th code, which as you point out, can call back to SQL. There's even more than one flavor of these extensions.


You could make the same argument against 'triggers': why not just write the code for them in your own app rather than making the SQL engine do the work? There's nothing special about triggers except that they make referential integrity easier to enforce.

05:10 Post: Request: stored functions/procedures (artifact: 5cb522bfb4 user: ronaaron)

Please add 'stored functions and procedures'.

Yes, you can create an additional function in C, but that requires changing C code etc, as opposed to adding some SQL to a database.

Since 'triggers' are essentially stored functions, it should be doable to add functions.

To make them useful, you would also need to have user-defined variables. Something like what I can do with MariaDB:

  SELECT NULL into @result;
  ... SQL stuff ...
  RETURN @result;

I'm finding that feature (of MariaDB) incredibly useful and would like to see it adopted in SQLite as well, if possible

14:12 Reply: SQLITE_HAS_CODE is gone? (artifact: ba2ef6a842 user: ronaaron)

While an interesting idea, it would be impractical since my product is a programming language which my clients use to make products for their clients. I don't see that as a great sell.

05:31 Reply: SQLITE_HAS_CODE is gone? (artifact: 74fac32030 user: ronaaron)

Right. Of course, I have customers using the existing encrypted db format, so I have to make sure that any VFS edition of the encryption is 100% backward compatible.

For now I'll content myself with applying new SQLite patches to the 3.31 code, since I don't have the time to dedicate otherwise.

03:53 Reply: SQLITE_HAS_CODE is gone? (artifact: 07c38718a9 user: ronaaron)

Thanks, Ulrich. You're exactly right: each page has a different nonce for encryption, so the CODEC interface was just perfect.

Looking at the SQLCipher project you mentioned, it looks like it does something very similar to what I am doing.

I would vastly prefer not to have to backport the CODEC interface or manually merge upstream changes to SQLite, but if DRH isn't going to provide the interface any more it looks like I have no choice.


03:50 Reply: SQLITE_HAS_CODE is gone? (artifact: f179e137a0 user: ronaaron)

That's markedly inconvenient for me...

What is your suggestion for reimplementing my total-encryption layer? Is the VFS interface sufficient for that?

12:53 Post: SQLITE_HAS_CODE is gone? (artifact: 08481b3fac user: ronaaron)

I was surprised to see that my code didn't compile with the latest SQLite source, due to SQLITE_HAS_CODEC having been removed. I was even more surprised to see no mention of that in the release notes.

Is there an alternative method for me to implement full-db encryption?