From: Wietse Venema on
Last weekend I talked with one of the creators of SQLite and was
impressed by the thoroughness of their code quality process.

I brushed up a patch that was circulated two years ago and spent
a day or so adding error checks and updating documentation.

Right now this is a read-only implementation (like mysql/pgsql)
but it may be worthwhile to add update support. SQLite implements
locking internally. That would allow us to avoid the problems with
Postfix's external locks on Berkeley DB maps, which are broken
after BDB version 2.

The documentation is practically identical to that of MySQL:

http://www.porcupine.org/postfix-mirror/sqlite_table.5.html
http://www.porcupine.org/postfix-mirror/SQLITE_README.html

Wietse

From: Patrick Ben Koetter on
* Wietse Venema <postfix-users(a)postfix.org>:
> Last weekend I talked with one of the creators of SQLite and was
> impressed by the thoroughness of their code quality process.
>
> I brushed up a patch that was circulated two years ago and spent
> a day or so adding error checks and updating documentation.
>
> Right now this is a read-only implementation (like mysql/pgsql)
> but it may be worthwhile to add update support. SQLite implements
> locking internally. That would allow us to avoid the problems with
> Postfix's external locks on Berkeley DB maps, which are broken
> after BDB version 2.

That's great news!

p(a)rick

--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>

From: Victor Duchovni on
On Fri, Jun 18, 2010 at 05:58:02PM +0200, Patrick Ben Koetter wrote:

> > Right now this is a read-only implementation (like mysql/pgsql)
> > but it may be worthwhile to add update support. SQLite implements
> > locking internally. That would allow us to avoid the problems with
> > Postfix's external locks on Berkeley DB maps, which are broken
> > after BDB version 2.
>
> That's great news!

Indeed. One still needs tools to insert data into the database.
Does Postfix need to provide a minimal interface for this, or do we
assume that SQLite users will have adequate tools outside Postfix.

Does Postfix need to do anything to indicate transaction boundaries
between its lookups? Or is not starting a transaction in the first place,
sufficient to indicate that each query is independent from all the others?

--
Viktor.

From: Brian Evans - Postfix List on
On 6/18/2010 12:07 PM, Victor Duchovni wrote:
> On Fri, Jun 18, 2010 at 05:58:02PM +0200, Patrick Ben Koetter wrote:
>
>>> Right now this is a read-only implementation (like mysql/pgsql)
>>> but it may be worthwhile to add update support. SQLite implements
>>> locking internally. That would allow us to avoid the problems with
>>> Postfix's external locks on Berkeley DB maps, which are broken
>>> after BDB version 2.
>> That's great news!
> Indeed. One still needs tools to insert data into the database.
> Does Postfix need to provide a minimal interface for this, or do we
> assume that SQLite users will have adequate tools outside Postfix.

At the very least, the documentation could link to the SQLite website
for tools..
http://www.sqlite.org/cvstrac/wiki?p=ManagementTools

From: Wietse Venema on
Victor Duchovni:
> On Fri, Jun 18, 2010 at 05:58:02PM +0200, Patrick Ben Koetter wrote:
>
> > > Right now this is a read-only implementation (like mysql/pgsql)
> > > but it may be worthwhile to add update support. SQLite implements
> > > locking internally. That would allow us to avoid the problems with
> > > Postfix's external locks on Berkeley DB maps, which are broken
> > > after BDB version 2.
> >
> > That's great news!
>
> Indeed. One still needs tools to insert data into the database.
> Does Postfix need to provide a minimal interface for this, or do we
> assume that SQLite users will have adequate tools outside Postfix.

A "postmap" option to create an SQLite file would make sense.

> Does Postfix need to do anything to indicate transaction boundaries
> between its lookups? Or is not starting a transaction in the first place,
> sufficient to indicate that each query is independent from all the others?

I'm not familiar with the SQLite API to know how explicit the hints
from the application need to be to make locking work. That would
be future work.

Wietse