Dominik Fässler <[EMAIL PROTECTED]> said:
> I changed almost of dbmail-src to work with libdbi. My main problem is
> to convert dbmsgbuf.c due to the two functions 'db_give_range_size'
> and 'db_dump_range'. I changed source in view of using it with
> Firebird, but both Firebird and Oracle not supports row_count
> functions, only by fetching all records before, what not really spares
> recouces.
[snip example code]
> In 'dbmsgbuf.c' the two functions calculates f.e. the size of the
> bodymessage. My question is: Is it possible to calculate the size
> on the fly by get 'si=+dbi_result_get_field_length_idx(res,0)' and
> realloc memory or is it possible to store Messages in one binary
> field? What do you think about this?
At one point we discussed having exactly one message block for headers and
exactly one message block for the entire body of a message. I'm personally
in favor of keeping our current code which splits messages up and which
knows how to put them back together again. But, even if everyone else
decided, "Aaron's being dumb, we're taking out the split up code" we'd
still have to keep the reassembly code that you're wrestling with.
/* Should work just fine, just add safety checks. */
pos = size;
size += dbi_result_get_field_length_idx(res, 0);
realloc(foo, size * sizeof(char));
foo[pos] = dbi_result_get_it_blah(res, 0);
I suspect that if you pull in some of the Glib and GMIME work that Paul,
Dan and Leif have been doing that you can simply throw the result fields
into an opaque data structure and not have to think too hard about it ;-)
Aaron
--
