While the MySQL 5.1 feature list looks quite tasty to me, the MySQL 5 feature list has not really won me over. Aside from the fact that most new MYSQL 5 features have been quite bug plagued (though this is now mostly resolved side from the performance issues with VIEW's and INFORMATION_SCHEMA). So Arjen is doing some courses on MySQL 5 features, which got me thinking which are the features I regularly use? Uhm .. I think there is only one, which are VIEW's. Actually I always end up using them for the same thing: Computing a status field that changes given the CURRENT_DATE. I tend to try and avoid cron jobs for these tasks whenever I can. Of course it would be more performant to update the status once, but replying on the status update cron job to actually work right at the expected time is tricky. Maybe with the event scheduler in 5.1 I will consider changing this VIEW use case.

I am very thrilled to hear that SUN is evaluating joining the SQL standard process. I feel that Peter would be the perfect candidate for this job too, given that he knows the standard inside out. My hope would be that this way the OSDB consortium (yes, I still believe) will get a liason to the SQL standards body. Also this way the much more down to earth real world approach of OSS databases to finding new syntax to add to SQL now has a chance to find its way into newer versions of the standard. It seems things are too late to ensure that SQL2008 will follow the popular LIMIT syntax, but in a way its already a huge leap forward that SQL2008 defines a way to get LIMIT/OFFSET without having to use some convoluted subquery. Chalk this one up as a new potential that came about with the acquisition of MySQL by SUN.

Ok, I will try to get some coherent writing done for emPHPower this week. Whatever I will produce will probably end up on my wiki sonner or later. I am also in the process of setting up a mailing list (or should I high-jack the orphaned evangelism mailing list for this?). I hope this all will lead to a few people to step up and really start getting involved deeply in emPHPower. Aside from this Sebastian has handed in a BOF session on emPHPower for OSCON. I hope this one will work out. It does not seem to be in the confirmed listing yet though. Also Cal has notified me that they have reserved a spot for emPHPower at the unconference happening at ZendCon. Since I will not be able to make the trip over to California, I am hoping someone else will step up and moderate a discussion on emPHPower. If anyone could also use the opportunity to engage the more business-y crowd at ZendCon to get their POV, it would also really help out a lot.

So I have now joined Johannes as a co-RM for PHP 5.3. Its quite an honor and a challenge. Especially since I still need to find enough OSS time to continue to work on emPHPower and write out a proper proposal for a "constitution" (expect a mailinglist to be setup soon). We hope together we have enough brain cycles to push put what is probably the biggest minor release in the history of PHP. Just take a look at the todo list and the scratchpad detailing all the additions. Speaking of the scratchpad, we really really really need more people helping to identify the changes in PHP 5.3.

So I took my concerns over prepared statements to the #postgresql IRC channel on freenode. I pointed out that I think there should be a way to get server side handling of placeholders in statements but without the additional overhead of a second round trip or the drawbacks of overly generic query plans due to not being able to use the parameters in the planning stage. Some people have noted that this feature is available in MSSQL. It also seems to be available in PostgreSQL in the form of PQexecParams and its even exposed in ext/pgsql, though it's only used for sequence reading in PDO_PGSQL. It would be really cool if it could be used when emulating prepared statements (probably with a PostgreSQL PDO attribute).