Re: Prepared Statements

Поиск
Список
Период
Сортировка
От Dmitry Tkach
Тема Re: Prepared Statements
Дата
Msg-id 3F1BF9C9.9060007@openratings.com
обсуждение исходный текст
Ответ на Re: Prepared Statements  (Fernando Nasser <fnasser@redhat.com>)
Список pgsql-jdbc
Fernando Nasser wrote:

> Dmitry Tkach wrote:
>
>>
>> Two things that stricke me here:
>>
>> - no mention of "security" stuff whatsoever. The sole purpose of
>> PreparedStatement according to this is to "efficiently execute this
>> statement multipe times",
>> not "to prevent slq injection attacks" or anything like that;
>>
>
> Because in "real" prepared statements there is no such risk.  The risk
> is the artifact of a bug in our client side simulation of prepared
> statements (not real prepared statements as per definition).

My point was that  the risk exists, when you do *not* use
PreparedStatements, right?
If the purpose of PreparedStatement was to eliminate that risk, it would
have been mentioned. But it is not. Because PreparedStatement has
nothing to do with the security. It is all about efficiency.


>> - it is *explicitly* stated that setObject () should be used for
>> "arbitrary type conversions";
>>
>
> Not that arbitrary.  There is a table specifying for each java type
> that the passed object is member of the proper JDBC type for the
> converted result.  Which must be the type of the field you are trying
> to specify the value for.
>
> So it is not that arbitrary.

It doesn't say *how* arbitrary. It just says "arbitrary". :-)
If you could only pass objects of types in that table, you would not
need setObject () - just setString(), setInt() etc... would suffice.
The whole idea of setObject () is to be able to pass in an argument for
each there is no specialized setter function.

Dima




В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Peter Kovacs
Дата:
Сообщение: Re: Prepared Statements
Следующее
От: Barry Lind
Дата:
Сообщение: Re: Fix for using JDK1.2 instead of JDK1.4 method in date/time/timestampToString