[rsyslog] RFC: On rsyslog output modules and support forbatchoperations
david at lang.hm
david at lang.hm
Mon Apr 20 21:01:10 CEST 2009
On Mon, 20 Apr 2009, Rainer Gerhards wrote:
>> -----Original Message-----
>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
>> bounces at lists.adiscon.com] On Behalf Of RB
>> On Mon, Apr 20, 2009 at 10:33, Rainer Gerhards
>> <rgerhards at hq.adiscon.com> wrote:
>>> Excellent, but let me re-phrase: if you have a PostgreSQL expert at
>>> 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
>> 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
> 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
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.
More information about the rsyslog