Discuss Pseudo Prepared Statements for mysql_ in the PHP Development forum on Dev Shed. Pseudo Prepared Statements for mysql_ PHP Development forum discussing coding practices, tips on PHP, and other PHP-related topics. PHP is an open source scripting language that has taken the web development industry by storm.
Time spent in forums: 1 Month 2 Weeks 1 Day 19 h 44 m 40 sec
Reputation Power: 813
well, I don't really see the point of "emulating" prepared statements. I mean, if people are willing to rewrite their whole database code, they should rather choose "the real thing" and use PDO/MySQLi. Why should they take this intermediate step just to replace everything again in a few years?
Time spent in forums: 5 Months 1 Week 4 Days 4 h 53 m
Reputation Power: 8969
Adding a new function and trying to use it in new/touched code doesn't sound like "rewriting their whole database code" to me.
It's not always fair to ask people to redo everything: there are a number of reasons why that might not be an option. If functions like this get them one step closer to doing it, or even if not but they realize this is more secure than what they have now, then I say it's worth it.
Time spent in forums: 2 Months 7 h 48 m 54 sec
Reputation Power: 7053
It's a useful little function, no doubt, but if the goal is to ease the transition into PDO or MySQLi it seems like it would be better build an interface that matches the API used by PDO / MySQLi - ie with prepare and execute. That way if they ever do actually decide to fully convert to the superior interfaces they won't have to rewrite as much code using your compatibility layer.
Also it's worth noting that the behavior of this function is not fully compatible with real prepared statements. It serves the same purpose as far as security goes, but this function allows things that normal prepared statement would not.
I think a bigger problem with the MySQL extension is that it's deprecated and slow. It's not actually that difficult to write secure code using them, as you've demonstrated.