Re: sqlite3

[Eric Abrahamsen]

Qiantan Hong <qhong@mit.edu> writes:

>> YUCK!!
>> 
>> That would break 45 years of Emacs tradition and practice.  In Emacs,
>> data are stored as PLAIN TEXT.  Even .elc files are pretty much plain
>> text.
> Or the way I’d like to put it, data are stored as S-EXP.
>> That is, text that you can examine with standard tools, such as grep,
>> awk, perl, less, ...., and C-s and friends within Emacs.
> So you can read, eval, print them, edit them structurally, and
> look at the beautiful and highly readable parentheses.
> I found myself read C 20 times slower than Lisp, not mentioning
> hexademicals!
>
>> Emacs has that already.  It's called an alist.  It becomes persistent
>> when you print it to a file, not a challenging project.
> Same thoughts. But jokes aside, they do have a valid point,
> which is reading/printing a big alist can get slow.
> I totally don’t see the need to introduce database to
> solve this problem though. I hereby call for a plain Elisp
> implementation of a log-structured object(or, CONSes) store.

Scanning the (very long) thread, I don't think anyone is proposing using
sqlite *by default* for any Emacs data storage, least of all the
customization interface. Customize is the perfect poster child for the
advantages of plain-text, Emacs-readable data formats. As others have
said, sqlite is great for very large stores of data, particularly if
data retrieval is performance-sensitive.

I'm excited about this only because, somewhat ironically, only external
packages can require a sqlite library and make use of it -- it's not
available for built-in libraries.