Im sorry I havent kept everyone updated on this. The short answer is, I
re-wrote the UDF architecture to support 'pluggable' languages. This was
done by switching the codebase from C to C++, defining a virtual base-class
api and sub classing it for both the current DLL system and a new embedded
There are a few problems:
MySQL does not currently support an internal query API so that a udf / perl
script could run queries internally - perhaps by spawning new threads, or by
re-using the current thread buffers. If the sub - select code is written
well in 4.0, this might suffice. Unfortunately this is beyond my individual
Perl does not currently support threads ( well ). This means that each
thread must spawn its own interpreter. This is expensive and significantly
slows down connection time. Perl 6 is *supposed* to be totally thread-safe,
but chances are that MySQL will be on 5.0 before we seen anything stable
from the perl6 camp ;).
What you can do with it now:
Write basic functions in perl + load them into the MySQL engine like so:
CREATE FUNCTION 'foo' PERL_SCRIPT 'my_functions.pl';
SELECT perl('reverse shift;','foo');
I would love to share the code with anyone that is interested, but it should
be reviewed and cleaned up before its even considered for merging with the
main code base. Like I said, I totally rewrote the UDF subsystem, so this
isnt just a minor patch.
----- Original Message -----
From: "Russell E Glaue" <russ@stripped>
To: "Dana Prescott Kennedy Powers" <dana@stripped>
Sent: Wednesday, June 20, 2001 8:43 AM
Subject: Re: Perl + Mysql
> Anything new with your work on embedded perl in MySQL
> Our last thread on this topic was great. I brought up the matter of
> possibly making PERL available on the SQL query level. This is PERL/SQL is
> to MySQL as PL/SQL is to oracle.
> Do we think this is more of a possibility with the status of both
> MySQL 4 and PERL 6?
> Russell E Glaue, Technologies Engineer & Integrator russ@stripped
> Center for the Application of Information Technologies
> WIU, 101 Horrabin Hall, 1 University Circle, Macomb, IL 61455
> On Fri, 30 Mar 2001, Dana Prescott Kennedy Powers wrote:
> > Ive been working for a while on embedding perl in the mysql server, and
> > Im wondering how interested anyone is in formalizing the code and
> > potentially merging it with the main codebase. Ive added a --with-perl
> > extention to configure which creates a unique perl interpreter space for
> > each connection. I added a function which will eval a perl expression
> > using extra arguments as stack values ( ie. select
> > perl('reverse($_);', table1.column1); ). I have convinced myself that
> > creating a perl extention ( similar to mod_perl's relationship to
> > mysql ) is possible - Ive done it ;) - and can be done in a clean and
> > stable way.
> > More dramatic things which I havent implemented:
> > Extention to CREATE FUNCTION which will load perl scripts instead of
> > dynamic libraries.
> > Extention to CREATE FUNCTION which allows inline function definition and
> > storage.
> > Mysql Connection API module which would allow perl to create new
> > connections and issue queries with them ( ? )
> > A more extensible embedded interpreter api ( perhaps for python or
> > I was a very active participant on the mysql mailing lists about a year
> > ago, and I recall someone sending a lone message about wanting to try
> > something like this - it actually prompted me to try it. Anyway, im not
> > sure if this has been done or discussed, but let me know what you guys
> > think.
> > As usual the benefit of perl is not necessarily speed of code, but speed
> > of coding.
> > dpk
> > ---------------------------------------------------------------------
> > Before posting, please check:
> > http://www.mysql.com/manual.php (the manual)
> > http://lists.mysql.com/ (the list archive)
> > To request this thread, e-mail internals-thread653@stripped
> > To unsubscribe, e-mail <internals-unsubscribe@stripped>