David, > every database that I have seen (including Oracle) has had the ability > to > create prepared statements and stored procedures from the text-based > database tool, so I'm not understanding why working with 'just strings' > isn't enough. could you explain more? >
While this is not really nice, let me ask a counter-question: how is this done for example in Oracle? All I have seen while reviewing manuals was that you need to call a series of APIs. Most importantly usually one where you specify buffer sizes - what is real pain, given the fact that we do not really want to be able to use this jumbo buffers just because there is an ultra-slim chance we may have one message per year that is that large (but that's another issue, let's not get to distracted at this point). [snip] > definantly making the queue support batches ;-) > > as I see it, that will benifit all output modules, not just the DB > ones. > and you are the only person who can do the queue support while there > are > others who can (and do) work on the DB modules themselves. > > I would expect it to take a bit of 'discussion' between the different > DB > folks for them to all agree on any new abstraction, no it's not > something > that can be started immediatly in any case. Unfortunately there are not that many *active* db folks. I guess n=2, me included ;) Anyhow, that doesn't mean it has priority. But the two issues, as I now see it, are entangled. For the queue optimization, I need a test environment and it better be a good one. File output is too fast to be a good one. Database output is perfect. So I would actually need to modify at least one db output to support the queue enhancements. Plus, that will actually tell me the fine print of enhancing the queue in the best possible way. I've started to look at the postgres module for that reason. Thinking over the situation, I then found out that what I am doing now is exactly the same thing, with exactly the same issues, that Luis Fernando does with Oracle. This cries for a generic approach, especially if it is not too much effort to generalize. The macro-approach goes into that direction: keep it simple, but don't go the full length of a minidriver model. Rainer > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
