In some email I received from Gianni Mariani <[EMAIL PROTECTED]> on Wed, 02 Jul 2003 01:18:47 -0700, wrote:
> lou wrote: > There is actually no <lock tables> semantics in pgsql so there is no > contention between queries. This is probably not a big deal for dbmail > but it can be for other applications. Depends how the operation is performed synchronously or asynchronously, 1st one is safe, 2nd one is faster, also the probability of having two queries modifying same row at the very same time is still there and without locks or serialization they will collide, so when I say <lock tables> I mean 'reserve some space in there for me mate'. Anyway you get the drift, it's the same with crossing a street: on the traffic lights is more safer and sometimes faster compared to when you try to cross it in the middle of high volume traffic where the probability of being hit grows also the amount of time required to find the right moment might grow as well. [...] > > > >Obviously, 'everything or nothing' approach rock ;) > >[...] > >>Because pgsql procedures automagically prepare statements and hence > >>there is a lot less "planning" going on. > >yes, but you can make pgsql analyze queries :) [...] > >>Also, you really don't want the C code to know too much about the > >>schema. (Encapsulation peeve on mine). [...] > >yes, but can you make it learn, or write it so generically. > > > This is imap/mail we're talking about. It's a done deal. You have a > dozen or 2 imap commands. Implement each one as a stored procedure (or > set of procedures). Simple 1.Parse imap message 2.call stored procedure > 3,return result. Have a generic mapping from command to stored > procedure and you can probably write all the stored procedures in an > afternoon. Changes to the schema and procedures means you won't even > need to re-start the imap server .... Okay, this can be achieved without have stored procedures, It's not that hard to write software which actually customizes itself. This sounds more like an embedded system rather than transparent application (in sense of available databases). Different thing is to generate those procedures from nothing.. which is not easy, but yeah, I think the best bet for now is to have 1 centralized db API+ (+ option for plugging or replacing stuff on the fly, without having the daemon restarted or killed or whatever). > >I'm trying to find the balance between pgsql/mysql db APIs in dbmail > >and basically merge them in one.. hope to find some time in the next few > >months;) > > > It will be a while before mysql gets there. Contrary to some opinions, > Postgresql has an extreme number of features and is rock solid compared > to mysql. I think it's a mistake to go for the least common denominator > of Postgresql and mysql. Postgresql 7.4 has a whole bunch of new ones in some cases MySQL is faster, you're not being biased, are you? ;-) My idea doesnt have to do with the database itself, how good it is or not, once it's going it can easily optimize itself and re-optimizes queries even rewrite them, since that would be an option available from this db API+ pluggins and whatsoever, and will also be automated, so the user doesnt have to do explain 'select * from my_ass where shits < now;. and so on .. (bad example eh?) > This is a very simple database so I suggest to create a (C++) interface > for each operation you want to do (imap command or otherwise) and have > an implementation of a processor that does each kind of message. CPP is quite expensive though, but the whole thing will be achieved in no time :) OOP is one of the things I like in programming:) By implemented you mean plugged in? cheers
