So everybody and their dog hopefully knows about SQL injection attacks these days. Most people should have also heard someone telling them that using prepared statements is the magic super fix to all of these issues. People slightly more in the know will have read that prepared statements lead to all sorts of issues. Some of which can be fixed with hacks (or eventually at the source). Some of which can only be solved of the source also exist of course. Some others can only be fixed with certain assumptions (like using the first set of data for generating the query plan), which might break the original use of prepared statements.

So yesterday I spend a few hours writing out an RFC for ifsetor() (note that I put it into the "declined" section). While working through the discussion again, I realized that I had forgotten an important detail in the discussion: Currently we cannot provide a true COALESCE() implementation, which allows for any number of parameters. As such I totally forgot why people felt that the pass by reference hack was considered by these people as a viable approach. I also finally documented in detail why the addition of the shorthand ternary operator "?:" in PHP 5.3 is no replacement either.

On my current project my team had to develop a portlet interface. Users can load portlets and organize them in multiple tabs with 3 columns per tab. They can reorganize the order of their tabs and move portlets within a tab an also move them to new tabs. Portlets are always placed at the top left when they get added or moved to a tab. Furthermore portlets and tabs can be removed, though the last delete operation can always be undone. All of this essentially required me to devise a plan for how to manage ordered lists inside an RDBMS.

Ok, so as the project moves on from our initial issues with Zend Framework we now come to really appreciate the transparent proxy support that Zend_Http_Client offers. A real time saver for us. But after this short praising I must once again get back to complaining about Zend Framework. We ran into a really hard to find bug in the cookie handling of Zend_Http_Client, which has been filed as a bug back in August 2007 against version 1.0.1 (today we are at 1.5.2). More over this is a bug that other similar packages have gotten over in 2004.

Do they exist? Do they make you money (or in the case of Firebird meaningfully extend your community)? Would you be unhappy if support would be dropped in PHP 5.3, in PHP 6.0? Do you have ressources to prevent this from happening, by taking ownership of the code in question? Are you interested in ensuring the availability of solid support in PDO? While I do not think support will be dropped in PHP 5.3 (well for FrontBaseSQL I have a hard time standing up in defense like I did for the other 3), there is a good chance this will happen in PHP 6.0. Without PDO support your users will be left more or less in the dust. So if you work for one of these vendors, please talk to who ever who can prevent this. If you know someone at these vendors, please contact them or give me the coordinates so that I can do this for you.