Hi,

On Dec 1, 2003, at 10:37 AM, Thomas Mueller wrote:

Hi,

I've checked out dbmail on 30 Nov and found some problems with
postgresql.

When I try to insert a message:
<snip log>
dbmail tries to access physmessages_id_seq, but there is only a sequence
physmessage_id_seq.
Stupid mistake (which isn't found when using MySQL..,
because it does not use the argument to the db_insert_result() function.

The maintenance task fails:
----------------------------------------------------------------------
# su dbmail -c "/usr/local/sbin/dbmail-maintenance -cfpd"
*** dbmail-maintenance ***
<snip log>

Again, this was a MySQL-ism. In SQL-92, one needs to have
all columns in the "HAVING" clause to be in the "GROUP BY"
clause, but MySQL does NOT demand this. So it slipped through.

From today on, my main testing platform will use PostgreSQL,
because it is much stricter than MySQL.


The man page of dbmail-config is still in cvs, the file should probably
be removed.
Fixed

The first problem led to a inconsistent database (the insert to
physmessage succeeded) - this could be easily solved using transactions.
I found a thread about using transaction on the dbmail list - are there
plans to use transactions for 2.0 ?
We'd like to use transactions, and make better use of foreign keys. It would be easiest to ditch MySQL ISAM tables completely, so that the we can use those features, and let the database handle the integrity of the tables. The less db-handling code in DBMail, the better.

I guess we need some discussions about this in this list and here at IC&S.

Anyway, thanks for pointing out these bugs. They're fixed in CVS and will be in the next snapshot.

Cheers,
Ilja

--
IC&S
Stadhouderslaan 57
3583 JD Utrecht
telnr. 030-6355730
faxnr. 030-6355731

PGP-key:
http://www.ic-s.nl/keys/ilja.txt

Reply via email to