Adding this collection as a project dependency would be opposite of "lean". Better to manually collect the functions you need, favoring the well maintained and tested sqlite code base over other sources.

sqlean's existence provides the kernel around which other things in the ecosystem can coalesce. For example, karlb's sqlite-sqlean pip module [1], which makes it easy to get these extensions in any Python project in a cross-platform manner.

I've used the math library myself recently: the SQLite in my distro is 3.31. I could install the tooling necessary to build a new SQLite, or I could use this project.

I also use the crypto library in my datasette-ui-extras library, which can run on a variety of end-user platforms. It's nice not to have think about the packaging myself.

To each their own, of course! But for me, calling this "mostly noise" is a disservice to its maintainers.

[1]: https://pypi.org/project/sqlite-sqlean/

Even the main set extensions are split into modules, rather than released as a single binary - so people can use them independently.

As for 'noise'. Well, good luck implementing `regexp_substr` and `regexp_replace` using the well-maintained and tested sqlite codebase. Or streaming file I/O.

I still haven't found a good, reliable method of upgrading the SQLite version that is made available to Python's "sqlite3" standard library module for example, that works reliably across Linux and macOS. https://til.simonwillison.net/sqlite/ld-preload is one mechanism I've explored, but it's not ideal.

As such, extensions which package stuff that you could get in SQLite core if you had a good way of recompiling that with extra options are really useful.

https://www2.sqlite.org/src/timeline?r=begin-concurrent-pnu-...

I can't find the thread.

That said, the rate of refinements and new features is quite impressive.

(I love that the author makes those available as Python packages as well:)

    import sqlite3
    import sqlite_regex
    
    conn = sqlite3.connect(':memory:')
    sqlite_regex.load(conn)
    conn.execute('select regex_version(), regex()').fetchone()
    # ('v0.1.0', '01gr7gwc5aq22ycea6j8kxq4s9

https://www.sqlite.org/fts3.html

, where it says: "Note that SQLite will process an SQL SELECT statement tree against an FTS table in three phases: ... The final phase rewrite the query from the inner join into an outer join.", and

https://www.sqlite.org/indexing_ft_only.html

, where it says: "the bookwith table can be faster if you omit the where clause and just ask for the full-text results for all of rows of bookwith." ?

And which is more useful for general-purpose website full-text search -- FTS, or a table with a _column called sqlite_fts_index=... ?

xattr -d com.apple.quarantine *

I've been considering using that: define Anyone have any experience with it?

Did you have any questions in particular?

https://www.sqlite.org/datatype3.html notes that:

> TEXT. The value is a text string, stored using the database encoding (UTF-8, UTF-16BE or UTF-16LE).

But if you want unicode-aware collations, LIKE operations etc you need this extension: https://www.sqlite.org/src/doc/trunk/ext/icu/README.txt

You can compile this in too, but from a quick review none of my various SQLite installations seem to have been compiled with the SQLITE_ENABLE_ICU flag.