Re: Prepared Statements - Mailing list pgsql-jdbc

From Dmitry Tkach
Subject Re: Prepared Statements
Date
Msg-id 3F1BF9C9.9060007@openratings.com
Whole thread Raw
In response to Re: Prepared Statements  (Fernando Nasser <fnasser@redhat.com>)
List 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 by date:

Previous
From: Peter Kovacs
Date:
Subject: Re: Prepared Statements
Next
From: Barry Lind
Date:
Subject: Re: Fix for using JDK1.2 instead of JDK1.4 method in date/time/timestampToString