Hi Ilja,
They're fixed in CVS and will be in the next snapshot.
I found 2 more problems. In my logs I see quite often:
Dec 6 17:27:01 server postgres[3043]: [5] ERROR: Attribute
blk.messageblk must be GROUPed or used in an aggregate function
Dec 6 17:27:20 server postgres[14828]: [6] ERROR:
Hi,
I've checked out dbmail on 30 Nov and found some problems with
postgresql.
When I try to insert a message:
--
Dec 1 01:56:55 debian dbmail/imap4d[15868]: dbpgsql.c,db_query:
executing query [INSERT INTO physmessage
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
On Mon, Dec 01, 2003 at 11:39:19AM +0100, Ilja Booij wrote:
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
On Mon, 2003-12-01 at 05:39, Ilja Booij wrote:
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
Aaron Stone wrote:
Dropping MyISAM seems like the right thing to do here. DBMail 2.0 could
reasonably require MySQL 4.0 or 4.1 as its minimum, along with whatever recent
version of PostgreSQL supports needed features, too (yeah yeah, flame away
that PostgreSQL supports everything we need and
