Paul J Stevens <[EMAIL PROTECTED]> said: > Thomas Mueller wrote: > >> At the moment queries seem to be spread over dbmail. Is it hard to use a >> more layered approach with a defined storage layer? A interface could be >> something like 'sl_retrieve_message(user, mailbox, condition)' where >> condition could be all/header=xyz/... > > Sounds a lot like what I'm working on. > > 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. 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? Aaron
