> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of RB > Sent: Monday, April 20, 2009 7:43 PM > To: rsyslog-users > Subject: Re: [rsyslog] RFC: On rsyslog output modules and support > forbatchoperations > > 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");
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). Rainer > _______________________________________________ > 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
