Re: Correct escaping of untrusted data

Geoff Caplan wrote:

> Are the standard escaping functions found in the PHP, Tcl etc APIs to
> Postgres bombproof? Are there any encodings that might slip through
> and be cast to malicious strings inside Postgres? What about functions
> like convert(): could they be used to slip something through the
> escaping function?

What about writing nessus plugin(s) or a specific scanner for these
escaping issues ? I don't know if a such thing already exists...

--
     Olivier