Perl is not interpreting those strings.
My guess is that you need to do read about placeholders and quote in the DBI documentation.
| MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!" | | I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README). | | ** The third rule of perl club is a statement of fact: pod is sexy. |
| [reply] |
Hi monks,
you are great!
I changed the double quotes into single quotes and every thing worked out fine.
Thank you very much,
Alexander
| [reply] |
You didn't post any code, but if you are not using placeholders as mentioned previously, perl will not interpolate anything inside single quotes '. To get a single quote into a single quote, just backslash escape it \'. | [reply] |
As the 2 posters above mentioned, use placeholders, and
also the $dbh->quote($string) method.
Most likely your errors, are related to data not being correctly escaped before being fed to the database.
This can also be a major security hole... for example...
$dbh->do("DELETE FROM table WHERE foo='$bar'");
Seems ok, until someone does something like this:
$bar = "x' OR ''='";
| [reply]
[d/l]
[select] |
Maybe you're doing something like this:
$email = "name@location.ext";
And only then you're inserting the contents of $email in the database. If so, @location will be interpreted, yes.
Ways to work around this:
- Escaping special characters: $email = "name\@location.ext";
- Single quoting: $email = 'name@location.ext';
- And other twisted ways: $email = "name@" . "location.ext"
The first one escapes the "@" sign, while the second one prevents variables from being interpreted inside the string.
The third one is just a proof that there is always another way... :-)
HTH | [reply]
[d/l]
[select] |
| [reply]
[d/l] |
I realise this has been said here already, but I don't think it can be emphasised enough. Use placeholders. Don't use DBI::quote, don't put your values directly in your statements, even if they're constants. Use placeholders. If your DB doesn't support them (which I doubt is the case for postgreSQL), get a better database. Heck, even DBD::CSV supports placeholders, there's no excuse.
Placeholders solve all DB-related problems from interpolating strings. All that you're left with is perl-related interpolation.
There are some limitations on placeholders - e.g., you can't set the table name with a placeholder very often (plays havoc with the preparation of the execution path, I suppose). But at least with tables, I doubt many DBs support [@'\s] in the table name anyway, so if you want to use $email as a table name, you've already got problems which placeholders couldn't solve.
| [reply]
[d/l] |