This is a summary of discussion with ELF about escaping string for SQL.
I recommmend addslashes()
(A) performance
(B) compatibility with environments of magic_quotes_gpc=on
(C) reverse function exists
(D) DB connection free
ELF recommend *_escape_string()
(1) clear the purpose
(2) searchable by grep, replacable by sed, easily
(3) can follow to change DB engine's spec
I think it stands to reason all of (1)(2)(3).
But I'll use addslashes() instead of mysql_real_escape_string() because I know the escaping rule of addslashes() exactly.
It will be much better to use accustomed tools than unaccustomed tools.
eg) I've just found a SQL Injection in a famous script because of developper's ignorance which ` can't be escaped by addslashes()/mysql_real_escape_string().
SQL文に対するリテラルのエスケープに関しては、セキュリティとかINJECTIONなんて概念が一般的になる前でも、プログラマに対して「正しくプログラムを動作させる為に必要」って教育がされますから。
余談ですが、PHPに関しては、簡易WEB作成ツールって位置付けで発祥した為かmagic_quote_gpcなんてのが最初から用意されていたがために、余計に混乱をもたらしているような気がします。これがために、少し前にはmagic_quote_gpc環境で無い場合にすべてのGPCに addslashesなんて処理が行われていた物もあったりします。
`(バッククオート)も'(シングルクオーテーション)と同様にエスケープされる、なんて勘違いがベースにあったように思えます。