In the case of (auto generated) placeholders I will pass a reference to the original value into DBI->bind_param() , so this will be fine.

It's the case of literals causing me headaches.

The raw concept in short:

• the DB-table is handled as a Perl package with it's proper namespace,
• the columns are constants in this package returning objects blessed into a class SQL::Column
• operators are overloaded for SQL::Column
• operations return objects of class SQL::Operation with nested attributes like {operator => "<", left =>  bless (['col'], '::Column'), right=> bless (["42"], '::Literal')
• higher syntax expressions like WHERE are just functions imported into that table package, dealing with the nested objects and returning another container object
• In the end I get an abstract syntax tree of nested objects which I can walk and translate to the target SQL dialect

So something like this

query {
    package t_table;
    WHERE 
        col < "42"
}
[download]

needs to distinguish if the literal was string "42" or 42

Of course I could think about overloading lt too, to have a more Perlish way to get the type (and crosscheck against the table's definition), but the more information I have to catch errors, the better.

I hope my approach is clearer now! :)