Roadmap?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Roadmap?

Thomas Kurz
I'd kindly ask whether there is some sort of roadmap for SQLite development?

Someone recently pointed out how much he loves the "lite" and well-thought features. I cannot see that: I observe that many "playground" gadgets keep being implemented (like virtual columns, virtual tables, FTS3/4/5, ...), where one might wonder about their relationship to "Liteness", whereas other features, essential basics of the SQL standards, are still missing and there is no indication they are to be added.

Without wanting to offend someone, I cannot see the logic in development, so: Is there some kind of roadmap?

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Darren Duncan
On 2019-10-20 12:53 a.m., Thomas Kurz wrote:
> I'd kindly ask whether there is some sort of roadmap for SQLite development?
>
> Someone recently pointed out how much he loves the "lite" and well-thought features. I cannot see that: I observe that many "playground" gadgets keep being implemented (like virtual columns, virtual tables, FTS3/4/5, ...), where one might wonder about their relationship to "Liteness", whereas other features, essential basics of the SQL standards, are still missing and there is no indication they are to be added.
>
> Without wanting to offend someone, I cannot see the logic in development, so: Is there some kind of roadmap?

The features you name don't take away from the "liteness", they are all quite
small and useful.

The main thing that provides the liteness is that SQLite is a single-user DBMS
implemented as an embedded library, in contrast to being a server with multiple
concurrent users.

What are the main missing "essential basics of the SQL standards" that you think
can be added without compromising the "liteness"?

-- Darren Duncan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Simon Slavin-3
In reply to this post by Thomas Kurz
On 20 Oct 2019, at 8:53am, Thomas Kurz <[hidden email]> wrote:

> I'd kindly ask whether there is some sort of roadmap for SQLite development?

Only private to the developers, probably just mentioning whatever they're worried about at the moment.  Nothing public.

> Someone recently pointed out how much he loves the "lite" and well-thought features. I cannot see that: I observe that many "playground" gadgets keep being implemented (like virtual columns, virtual tables, FTS3/4/5, ...), where one might wonder about their relationship to "Liteness", whereas other features, essential basics of the SQL standards, are still missing and there is no indication they are to be added.

It's worth remembering that almost all of the literally billions of installations of SQLite are in mobile phones or embedded controllers inside single-purpose machinery (e.g. your TV recorder, a crane balancing management system, a car-park ticketing system).  These devices don't need complete implementations of SQL, they need fast response, low memory use, and low power use.  That's why SQLite stays 'Lite'.

You are never going to see a full implementation of SQL in SQLite.  Here's why: the SQL standard is set out in ISO/IEC 9075-1:2016.  It has 9 parts, and over half a megabyte of text.  It's copyrighted, huge, difficult to understand, and almost nobody cares about more than three chapters of it.  One copy costs around €162.  Which would arguably be wasted since it gets reviewed and changed every two or three years, including right now.

But you – yes, you ! – can get your features included in SQLite.  Just join the SQLite consortium for US$85K/year.

<https://www.sqlite.org/consortium.html>

Those are the people who pay for SQLite.  They get personal support and their own requirements catered for, up to and including new features, instant bug fixes, code examples and customised test suites for their chosen compilation options.  The recent addition of support for the "WITH" construction was added because a consortium member requested a way to implement something, and that's how SQL does it.

Alternatively make a suggestion that

(a) lots of people want
(b) will be simple to explain in the documentation
(c) doesn't require significant work
(d) doesn't make the source code or object code much bigger
(e) won't break backward compatibility
(f) doesn't add significantly to the test suite
(g) doesn't violate the SQL way of doing things
(h) the developers like

(I think that's everything I've seen discussed here.)  For example, BOOLEAN affinity has been frequently suggested, but the developers said adding tests for BOOLEAN type values to the test suite would be a lot of work, and make it take far longer to run because everything that handles values would have to be tested with BOOLEAN values.  Another common request is full support for Unicode (searching, sorting, length()).  But even just the tables required to identify character boundaries are huge.

You are, of course, free to fork SQLite and add in all the features you want.

Hope this helps.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Dan Kennedy-4
In reply to this post by Thomas Kurz

On 20/10/62 14:53, Thomas Kurz wrote:
> I'd kindly ask whether there is some sort of roadmap for SQLite development?
>
> Someone recently pointed out how much he loves the "lite" and well-thought features. I cannot see that: I observe that many "playground" gadgets keep being implemented (like virtual columns, virtual tables, FTS3/4/5, ...), where one might wonder about their relationship to "Liteness",
> whereas other features, essential basics of the SQL standards, are still missing and there is no indication they are to be added.

Feel free to make suggestions. Which missing feature or features causes
you the most bother?

Dan.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Jens Alfke-2
In reply to this post by Thomas Kurz

> On Oct 20, 2019, at 12:53 AM, Thomas Kurz <[hidden email]> wrote:
>
> many "playground" gadgets keep being implemented (like virtual columns, virtual tables, FTS3/4/5, ...),

I suspect you are used to database servers, and haven’t used SQLite as an embedded library inside an app (its primary use case.) Virtual tables and table-valued functions are extremely useful there, as are a bunch of other features that probably seem like “playground” to you, like C functions and pointer types. The product I work on would be impossible without these.

As for FTS, I can’t see how anyone would consider it frivolous! Full text search is very common, something many apps with structured storage eventually need, and found in a lot of big database servers. (You didn’t mention geo-queries, but the same goes for those. And for obvious reasons they’re especially good to have in mobile apps.)

I’m curious which extra SQL features you think should be added? And what your use case is?

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Rowan Worth-2
In reply to this post by Simon Slavin-3
On Sun, 20 Oct 2019 at 17:04, Simon Slavin <[hidden email]> wrote:

> Another common request is full support for Unicode (searching, sorting,
> length()).  But even just the tables required to identify character
> boundaries are huge.
>

Nitpick: there are no tables required to identify character boundaries. For
utf-8 you know if there's another byte to come which is part of the current
codepoint based on whether the current byte's high bit is set, and
furthermore you know how many bytes to expect based on the initial byte.

I'm less familiar with utf-16 which SQLite has some support for, but a
quick read suggests there are exactly two reserved bit patterns you need to
care about to identify surrogate pairs and thus codepoint boundaries.

Tables relating to collation order, character case, and similar codepoint
data can of course get huge, so your point stands.
-Rowan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Darren Duncan
Rowan, you're talking about Unicode codepoints; however, Unicode graphemes, what
typical humans consider to be characters, are sequences of 1..N codepoints,
example a letter plus an accent that get composed together, and this is what
takes those large tables; this is related to Unicode Normal Forms, eg NFD vs
NFC, and its not about codepoint encodings like UTF-8 vs UTF-16 etc. -- Darren
Duncan

On 2019-10-20 8:03 p.m., Rowan Worth wrote:

> On Sun, 20 Oct 2019 at 17:04, Simon Slavin <[hidden email]> wrote:
>
>> Another common request is full support for Unicode (searching, sorting,
>> length()).  But even just the tables required to identify character
>> boundaries are huge.
>
> Nitpick: there are no tables required to identify character boundaries. For
> utf-8 you know if there's another byte to come which is part of the current
> codepoint based on whether the current byte's high bit is set, and
> furthermore you know how many bytes to expect based on the initial byte.
>
> I'm less familiar with utf-16 which SQLite has some support for, but a
> quick read suggests there are exactly two reserved bit patterns you need to
> care about to identify surrogate pairs and thus codepoint boundaries.
>
> Tables relating to collation order, character case, and similar codepoint
> data can of course get huge, so your point stands.
> -Rowan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Warren Young
On Oct 20, 2019, at 9:20 PM, Darren Duncan <[hidden email]> wrote:
>
> Rowan, you're talking about Unicode codepoints; however, Unicode graphemes, what typical humans consider to be characters, are sequences of 1..N codepoints, example a letter plus an accent that get composed together, and this is what takes those large tables; this is related to Unicode Normal Forms, eg NFD vs NFC, and its not about codepoint encodings like UTF-8 vs UTF-16 etc. -- Darren Duncan

+1.  strlen() and character indexing on UTF-8 text is nontrivial:

    https://stackoverflow.com/q/6162484/142454

Points 10, 27, 46, 47, and 48 under “Assume Brokenness” are relevant here.

If you’re not seeing that Perl’s handling of Unicode and thus that the accepted answer by one of Perl’s best practitioners matters here on the SQLite mailing list (which is to say, not Perl) the point is that Perl’s implementation of Unicode is one of the best available among the set of languages designed before Unicode became popular, so if you want a model to learn lessons from, it’s one of the best you could pick.

If you read this answer and don’t learn anything, you’re either too ignorant to understand what you’ve read and need to shore up the basics first, too arrogant to learn, or one of a very small number of people who truly understand Unicode.  I re-learn something every time I read this answer, because I’m not so deeply steeped in Unicode arcana to retain it all long-term.

And it’s a *summary*!  More weirdness awaits!
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Roadmap?

Hick Gunter
In reply to this post by Thomas Kurz
The "virtual table playground gadget" was our primary reason for selecting SQLite in the first place, because none of our production data sources are native SQLite tables. Instead, we have about 20 virtual table modules that implement about 1000 virtual table instances.

-----Ursprüngliche Nachricht-----
Von: sqlite-users [mailto:[hidden email]] Im Auftrag von Thomas Kurz
Gesendet: Sonntag, 20. Oktober 2019 09:53
An: SQLite mailing list <[hidden email]>
Betreff: [EXTERNAL] [sqlite] Roadmap?

I'd kindly ask whether there is some sort of roadmap for SQLite development?

Someone recently pointed out how much he loves the "lite" and well-thought features. I cannot see that: I observe that many "playground" gadgets keep being implemented (like virtual columns, virtual tables, FTS3/4/5, ...), where one might wonder about their relationship to "Liteness", whereas other features, essential basics of the SQL standards, are still missing and there is no indication they are to be added.

Without wanting to offend someone, I cannot see the logic in development, so: Is there some kind of roadmap?

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___________________________________________
 Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0

May be privileged. May be confidential. Please delete if not the addressee.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Richard Damon
In reply to this post by Rowan Worth-2
On 10/20/19 11:03 PM, Rowan Worth wrote:

> On Sun, 20 Oct 2019 at 17:04, Simon Slavin <[hidden email]> wrote:
>
>> Another common request is full support for Unicode (searching, sorting,
>> length()).  But even just the tables required to identify character
>> boundaries are huge.
>>
> Nitpick: there are no tables required to identify character boundaries. For
> utf-8 you know if there's another byte to come which is part of the current
> codepoint based on whether the current byte's high bit is set, and
> furthermore you know how many bytes to expect based on the initial byte.
>
> I'm less familiar with utf-16 which SQLite has some support for, but a
> quick read suggests there are exactly two reserved bit patterns you need to
> care about to identify surrogate pairs and thus codepoint boundaries.
>
> Tables relating to collation order, character case, and similar codepoint
> data can of course get huge, so your point stands.
> -Rowan

My memory is that Unicode is somewhat careful NOT to define what is a
'character' because that can really get complicated, and often
application specific about what it wants.

You have code-units, which for utf-8 are basically bytes.

You have code-points, which is what most people think of as a
'character' which has a single Unicode Codepoint number.

Then you have Graphemes, which are clusters of code-points that tend to
be expressed in a single glyph in output. (and some code-points don't
generate any output).

Dealing with Graphemes gets complicated, and that is where you run into
the need for lots of tables. Code-points them selves are fairly simple
to deal with, the problem is that in some langauges just dealing with
code-points doesn't let you fully handle some of the 'simple' operations
like sorting, or case folding with 100% accuracy, that sometimes
requires dealing with code-point clusters.

But, you also run into the issue (as I understand it) that Unicode
doesn't really define a universal ordering for all characters, that this
can be a language specific problem, and Unicode can't really solve that
issue. (Two langauges might use some of the same characters, but treat
them differently for sorting).

--
Richard Damon

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Thomas Kurz
In reply to this post by Darren Duncan
> The features you name don't take away from the "liteness", they are all quite
small and useful.

Yes of course they are useful, I wouldn't deny that. But they are prioritized over SQL-basics, that's what I'm confused about.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Thomas Kurz
In reply to this post by Dan Kennedy-4
> Feel free to make suggestions. Which missing feature or features causes
you the most bother?

Thanks, Dan.

To me, the most puzzling thing is the lack of full ALTER TABLE support (DROP COLUMN, MODIFY COLUMN, ADD CONSTRAINT, DROP CONSTRAINT). Modifying tables is some kind of science in SQLite, and thus, very error-prone. I'd be willing to donate for that but as a private user I cannot affort 85 k$ ;-)

If you are collecting suggestions, here's some ideas:

- RIGHT JOIN
- Time periods, temporal referential integrity, temporal predicates from SQL:2011
- native geospatial support (storage using well-known binary representation from Open Geospatial Consortium); I know there's Spatialite, but there are massive bugs in Spatialite that imho arise only due to the lack of basic native geo support

Some non-standard but very useful behaviors from other RDBMs:

- ON UPDATE CURRENT_TIMESTAMP (from MySQL)
- SHOW TABLES, SHOW COLUMNS, etc. (from MySQL)
- RETURNING (from Postgres)

(I have left out some things I know about that they have already been discussed recently, like DATETIME.)

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Thomas Kurz
In reply to this post by Jens Alfke-2
> I suspect you are used to database servers, and haven’t used SQLite as an embedded library inside an app

Yes and no ;-)

I have used database servers, and I am currently (for about 2 years) using (and appreciating!) SQLite library.

> Full text search is very common

Yes, of course. I didn't mean to deny that. I was just wondering why it's got priority over SQL-standards (because, as far as I know, but I might be wrong here, FTS is not part of one the SQL-standards).

> You didn’t mention geo-queries

Geospatial support would be one of the features I would *LOVE* to see in SQLite :-)

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

J. King-3
In reply to this post by Thomas Kurz
On October 26, 2019 8:07:57 p.m. EDT, Thomas Kurz <[hidden email]> wrote:

>To me, the most puzzling thing is the lack of full ALTER TABLE support
>(DROP COLUMN, MODIFY COLUMN, ADD CONSTRAINT, DROP CONSTRAINT).
>Modifying tables is some kind of science in SQLite, and thus, very
>error-prone.

I'd second this (that altering the schema is error-prone). I'm not puzzled by SQLite's omission of most table altering (a good designer will choose a good schema from the start and thus rarely need to change it, making schema alteration a bit more of a niche feature), but it has been a point of difficulty in getting people used to other databases to take SQLite seriously.

Earlier this year I spent some time implementing support for SQLite in Movim, a Web-based XMPP client and social media platform. All went smoothly until it was discovered that neither database schema migration library Movim uses actually correctly handles SQLite (despite both claiming to do so). I started fixing up one of them (Phinx), but got bogged down half-way because, of course, the whole thing assumes the database is capable of arbitrary ALTER TABLE statements.

For now Movim no longer supports SQLite, despite there being demand for it, for want of good tooling to perform schema alterations.


--
J. King
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Jens Alfke-2
In reply to this post by Thomas Kurz

> On Oct 26, 2019, at 5:12 PM, Thomas Kurz <[hidden email]> wrote:
>
> Geospatial support would be one of the features I would *LOVE* to see in SQLite :-)

SQLite has had geospatial support for years via the r-tree extension, and more recently GeoJSON.

As for time stamps ... I’ve been using SQLite since 2005 and have never felt the need to have it do more with dates than store a numeric timestamp in seconds-since-Unix-epoch. I have access to a lot of powerful platform APIs to do stuff with dates, so I don’t feel a need to have the database do similar things for me.

—Jens
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Warren Young
In reply to this post by J. King-3
On Oct 26, 2019, at 6:28 PM, J. King <[hidden email]> wrote:
>
> a good designer will choose a good schema from the start and thus rarely need to change it

When you add new features to a long-lived application, you may occasionally have to ALTER the table(s) the app uses to allow the new feature.  My company’s primary product has seen roughly two such DB alterations per year over its history, on average.

(The alterations are probably slowing down in truth, as we asymptotically approach perfection.  Hah!)

SQLite has you covered when the alteration is just to add a new column or rename an existing one, but that’s not every case I’ve run into over my time writing DB-based software:

1. We added some DB columns in version N of our software to support new features required by clients, but then something like 5 years later, that technology dropped out of current use, so we dropped the feature and thus dropped those supporting DB columns.

2. We extended an existing feature of the software to allow new functionality, requiring DB table additions, then several major versions later we replaced that sidecar’d feature with a wholly new tech stack, including its own DB tables, so we dropped those intermediate-form DB columns after migrating the data.

3. An existing DB table had to have a column added to make the PRIMARY KEY unique again after we added a feature that would have allowed that column to hold duplicate data; the second column disambiguated the cases.  SQLite lets you add the new column, but not change a table’s primary key without creating a new table and copying the data.

SQLite avoids some of the need for this with its dynamic typing and its unwillingness to enforce length limits.  We have several historical cases where we were using another DBMS and needed ALTER TABLE calls not allowed under SQLite to change column types or to widen fields.

For example, we had a table that started out using an 8-bit data type to hold a TV channel number, since the highest channel number at the time was 125, so 8 bits was actually one more than we really required.  Then digital TV happened.  Then IPTV happened.  Then OTT happened.  Now we just have a string column and a bunch of logic to figure out whether the string is an analog TV channel number, a digital TV channel number, an IP address, a URL…  If we’d been using SQLite from the start, we could have just kept using that “TINYINT” column to hold all of this, but ick.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Darren Duncan
In reply to this post by Thomas Kurz
On 2019-10-26 4:38 p.m., Thomas Kurz wrote:
>> The features you name don't take away from the "liteness", they are all quite
> small and useful.
>
> Yes of course they are useful, I wouldn't deny that. But they are prioritized over SQL-basics, that's what I'm confused about.

What do you mean by "SQL-basics"?

If you mean the list from your next post, there's very little basic about those
and many are quite complicated.

I agree with adding more ALTER TABLE options but that's about it.

Omitting RIGHT JOIN is good, that's a misfeature and LEFT JOIN does everything
useful it does.

Omitting SHOW TABLES or similar MySQL-only things is good, those are
misfeatures, and querying INFORMATION_SCHEMA does everything better and in a
more standard and composable way.

Anything to do with temporal and spatial is actually quite complicated, both
data types and constraints, and omitting those is quite reasonable.

-- Darren Duncan
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Thomas Kurz
> Omitting RIGHT JOIN is good, that's a misfeature and LEFT JOIN does everything
useful it does.

With all dear respect, but I don't think that it is up to you to define what a "feature" and a "misfeature" is. iirc, RIGHT JOIN is declared in SQL92, it is part of the SQL standard, and therefore it is one of the "SQL basics" I mentioned. And it's not a big thing either.

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Thomas Kurz
In reply to this post by Darren Duncan
> What do you mean by "SQL-basics"?

I forgot to mention that at least some basic math would be very helpful as well. I don't want to suggest a complete math support, that would really be far away from liteness, but the discussion standard deviation has shown that at least STDEV and POWER would be very helpful if they part of SQLite core.

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap?

Simon Slavin-3
On 27 Oct 2019, at 9:12am, Thomas Kurz <[hidden email]> wrote:

> the discussion standard deviation has shown that at least STDEV and POWER would be very helpful if they part of SQLite core.

These are presentation issues.  Not database issues.   The results of such calculations are unlikely to be used to decide on the continuation of a SQL statement.  Yes, "WHERE a < (b POWER c)" exists, but how often would you need it in real life ?

SQLite is a database system.  We shouldn't start to extend it to a presentation layer.  Especially since it can't do something more fundamental than STDEV: return all surnames starting with the Unicode character 'Å'.

I'm not entirely against adding facilities to SQLite.  But I feel that they should be database things, not presentation things.  For example, I think supporting more ALTER TABLE would be worthwhile.  And I agree with you on RIGHT JOIN: it may duplicate what can be done with LEFT JOIN but many SQL facilities are duplicates.  It's in SQL92 and people expect to see it.  I am sometimes also in favour of adding a BOOLEAN type, even though it does not appear in SQL92.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12