Ok, i will see that i craft a statement for postgres tomorrow that will work with the actual schema. That woukd provide me with a sufficient testbed.
rainer ----- Ursprüngliche Nachricht ----- Von: "[email protected]" <[email protected]> An: "rsyslog-users" <[email protected]> Gesendet: 20.04.09 21:01 Betreff: Re: [rsyslog] RFC: On rsyslog output modules and support forbatchoperations On Mon, 20 Apr 2009, Rainer Gerhards wrote: >> -----Original Message----- >> From: [email protected] [mailto:rsyslog- >> [email protected]] On Behalf Of RB >> >> On Mon, Apr 20, 2009 at 10:33, Rainer Gerhards >> <[email protected]> wrote: >>> Excellent, but let me re-phrase: if you have a PostgreSQL expert at >> hand, >>> that would be even more useful (I can do testing with PostgreSQL >> myself, but >>> do not have access to Oracle - I overlooked that tiny little >> restriction when >>> posting ;)). >> >> Perhaps more importantly for implementation-specific bits, perhaps we >> could clarify which we're discussing: procedures, functions, or >> prepared statements? The thread seems to jump back & forth between >> stored procedures and prepared statements, and although they are >> similar and often have a pure-SQL interface, they are not implemented >> everywhere. >> >> MySQL: PREPARE, CREATE PROCEDURE, CREATE FUNCTION >> PostgreSQL: PREPARE, CREATE FUNCTION >> Oracle: CREATE PROCEDURE, CREATE FUNCTION >> >> So, for PosgreSQL, you'd do something like Luis' earlier post: >> >> PREPARE rsyslog_insert(date, text) AS >> INSERT INTO foo VALUES($1, $2); >> EXECUTE rsyslog_insert('20090420-06:00', "log1"); >> EXECUTE rsyslog_insert('20090420-06:00', "log2"); >> EXECUTE rsyslog_insert('20090420-06:00', "log3"); so this would be DBInit="PREPARE rsyslog_insert(date, text) AS\nINSERT INTO foo VALUES(\$1, \$2);" DBStart = "begin\n" DBMid = "" DBEnd = "end" DBItem = "EXECUTE rsyslog_insert('$timestamp','$msg');\n" note that in DBInit you have to be careful about the $, escape them, use single quotes, or otherwise make sure they are in the resulting string > The real issue, as I see it, is "string vs. API call". Your sample above is > API-call, and this requires different ways of doing things. David is > suggesting doing EVERYTHING via a single exec() API call and that API > receives a single string. The string then describes the different modes. I > doubt that the single string approach actually works across databases (but > may be wrong ;)). > > Thus it is not so important if it is prepared statement or stored procedure > or whatever - and I pick whatever seems to be useful to prove that it can't > be done via a single API call with different strings. The most problematic > part seems to be prepared statements, thus we slowly converge into that > direction. > > Hope that clarifies (else *please* give me a wakup-call). what the different databases send out over the wire can look exactly the same (and it _is_ a string), sometimes your programming API provides the strings to a exec() API call, sometimes you make other API calls to create the string. so you could have exec('PREPARE rsyslog_insert(date, text) AS\n INSERT INTO foo VALUES($1, $2);') or you could have create_prepared_statement(rsyslog_insert(date,text), 'INSERT INTO foo VALUES($1, $2);') but what goes out over the wire is the same thing. 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
