Hi Aaron, > >> At the moment queries seem to be spread over dbmail. Is it hard to use a > >> more layered approach with a defined storage layer?
> > The retrieval api must indeed be totally opaque, while still allowing full > > control over retrieval-conditions. Returning cursors where possible, and > > fake-cursors when not seems like a very good idea that aligns nicely with > > db-apis used elsewhere. > > DBMail 2.0 undid the full database separation, which has yielded a much > easier to maintain database interface. We still have drivers for each of > the databases, but they are just for providing a query interface. Perhaps > we can simply build additional features into the driver layer. I would > really prefer not to go back to two entirely separate sets of queries and > such. I don't think that's possible - using direct queries and a cursor based approach is completely different. The latter requires a interface like: begin() -> create the cursor next() -> move the cursor and fetch the next result end() -> close the cursor To use that with MySQL we have to do: begin() -> SELECT all results next() -> return the next result from result set end() -> null The 'select all' approach is a bad idea: a dozen user can let the server running dbmail-imapd swap to death ... Maintenance would be harder, but probably we would only get two classes of database drivers: MySQL and everything else. > Alternatively, is there something really simple like a flag we can pass > with the query that tells PostgreSQL not to cache the entire result set? PostgreSQL doesn't cache anything, the result set is saved on the client side, not on the server side. The way it's done at the moment is easy to maintain but brings down the database interface to the lowest common denominator - and unfortunately that is really low ... The normal way to retrieve a larger result set is to use a cursor if you don't need all at once (because you want to search on the client side/display all results or something like that). Thomas -- http://www.tmueller.com for pgp key (95702B3B)
