Re: Re: MySQL has transactions

> I haven't seen the new mysql.  My feeling is that all things being
> equal, gluing transactions on top of a database implementation can
> not possibly be as stable and correct as building them in from the
> beginning.  The design heuristic that applies is "Make it run first,
> THEN make it run fast."  Mysql was built to run fast from the
> beginning, and now they're jamming in functionality.  So if I needed
> transactions I'd go with postgres until mysql has a track record.

You may be right, though they did this with berkeley db, which I guess is
pretty stable with transaction support.

The problems I'm having with postgresql are mainly in the area of blobs.  I
need to store several binary objects, generally in the 800-2400 byte range,
and I also need to store text messages sent by people, and I have to deal
with truncation and such to stay within the 8k row-size limit.  I've heard I
can update the blocksize to 32k, but then I've read this has other negative
impacts and that 7.1 solves it anyway -- but when will that be stable and
ready?

Anyway, I'm giving them both a quick test, primarily with regard to
transactions and blobs.  I can report back what I learn, but it will only be
at a testing level, and I'd prefer to hear from production users.

David