– Stored procedure to do backups:
Not in practice. Reason: you are limited to single thread (so no concurrent export). Table data export is OK, but how about triggers, routines, events? These are not easily exported since the “CREATE” statement is not easily reproducible on server side: you can’t SHOW CREATE TRIGGER…INTO OUTFILE, so you have to construct the CREATE statement yourself, based on I_S. This is actually the type of stuff I do actually do on common_schema, but I would regard it as unsafe to do backups this way.

UDF’s: not too useful: a UDF doesn’t get access to queries. It’s a C code, and you can do whatever you want with it, which is cool, but it is not integrated back with your SQL. So you can work wonders with aggregation functions, CPU intensive text matching etc. But you can’t easily SELECT from your tables (you have to open a new connection just like everyone else).

CPAN/PEAR is Henrik Ingo’s dream for MySQL. He said common_schema is the closest replacement for now.
It would be very cool – and I don’t see this happening…

What’s your view on UDF’s?

Should MySQL need a PIP/PEAR/CPAN/PGXN?