Good point. My concern is that this is not exactly safe if the Data Access Layer is unknown or not part of the package.

In my case I'm built on top of Class::DBI so as a 3rd party programmer, I have no idea whether Class::DBI is playing safe using placeholders and quote. Sure, I can look for myself in the source, but what if I change DAL to a completely different layer or module?

When in doubt, the wise decision would still be not to accept any user input unless I'm sure it's safe, long before I pass it into a DAL. For that matter, let's assume there is no DAL. Then sanitizing user input is still my job.

Class::DBI does use placeholders. Changing to a Perl-based DAL that doesn't use placeholders would be really, really stupid. DBI always supports placeholders (even if the underlieing database doesn't), and the additional security and caching support they provide make it reckless to not use them. If there is no DAL, then it's up to you to use placeholders.

I'm not saying to ignore input checking (I always do it even when I know placeholders will be there), but to put the problem in perspective.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

DBI always supports placeholders (even if the underlieing database doesn't)

While this is mostly the case there are exceptions. One that is fairly significant given the number of people using MS-SQL is DBD::Sybase with FreeTDS, which does NOT support placeholders at the moment, because of a lack of support for placeholders in FreeTDS's version of the Client Library API (which is what DBD::Sybase uses.)

Other systems or combination of front-ends and database engines may have similar problems.

Michael