About my shell extension implementing ".blobextract" and ".blobreplace" commands, Richard Hipp writes: "apparently uses the incremental BLOB I/O interface to avoid the need to load entire images into memory." and "That is nice, but on a modern workstation with many GB of RAM, is it really necessary? Maybe in some obscure cases. But in the common case of a smaller BLOB (a few megabytes) I think custom functions would work better:"
Yes, that is much better for BLOBs where memory does not become a limiting factor. It has a nice property I think of as "composability". I wrote the extension when I was using a cute little TCL virtual filesystem using SQLite for storage and BLOBs for file content. My thinking was that I did not wish to impose an artificial size limit in the shell, which I consider a useful tool for all kinds of things, including what I may dream up later. I dislike having seemingly reliable, simple tools suddenly pop up as failure points, blocking my workflow with their limitations. As I told Simon, it would be nice to combine the composability of the extension functions with the memory gentleness of SQLite's incremental BLOB I/O. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
