At 11:13 PM 7/26/2004, Tom Lane wrote:
>I think you misunderstood. Escaping is perfectly safe (given a correct
>escaping function) if it's used on *every* untrustworthy input string.
>The argument for the "keep data separate from code" approach is
>essentially just that it's easier to be sure you haven't forgotten
>anyplace where you need to escape.
Just curious on what are the correct/official ways for dealing with the
following scenarios:
1) Input string contains % and _ and would be used in a LIKE query that
should not have user controllable wildcards.
2) Input string are numbers which can hold negative and positive values and
could potentially be used in the following query:
update tablea set a=10-$inputstring where key=1;
When I tested at least one version of DBD::Pg doesn't appear to escape the
inputstring when it's a number.
e.g.
$SQL="update tablea set a=10-? where key=1";
And $SQL is used in a prepared statement with $inputstring as a parameter.
I found that when $inputstring contained a negative number, all rows in
tablea are set to the same value.
3) Postgresql queries with select .... from ... where ... LIMIT $inputstring
Postgresql 7.3.4 doesn't like LIMIT '1'
Nor does it like LIMIT '1'::integer
Haven't checked OFFSET.
(sorry- I downgraded to 7.3.4 and haven't upgraded).
Regards,
Link.