Why not just use simple Statement instead of PreparedStatement and
construct the SQL with concated string or StringBuilder? like this:
int col1=xxx;
String col2="xxxx";
String sql="select * from table where col1="+col+" and col2='"+col2+"'";
于 2012/7/26 3:59, Vinicius Abrahao 写道:
On Wed, Jul 25, 2012 at 4:26 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
On Wed, Jul 25, 2012 at 2:17 PM, Vinicius Abrahao <vinnix.bsd@xxxxxxxxx> wrote:
On Wed, Jul 25, 2012 at 3:45 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
Note that it seems the preparing/planning interaction was not the
poster's actual problem, but it may have been yours. As Tom Lane notes
in that thread, this should get better in 9.2.
jdbc should get some blame too -- it's really aggressive about
preparing queries.
indeed!
Is there any reason for that?
IMNSHO it's an oversight in the core JDBC design dating back to the
beginning: you have two basic choices for executing SQL. The
unparameterized Statement or the parameterized PreparedStatement.
There should have been a 'ParamaterizedStatement' that gave the
expectation of paramaterization without setting up and permanent
server side structures to handle the query; libpq makes this
distinction and it works very well. Of course, there are various ways
to work around this but the point stands.
That is true, I was observing the same, days ago:
Running queries and statments in jdbc:
https://github.com/vinnix/JavaLab/blob/master/Scrollable.java
And running queries with libpq:
https://github.com/vinnix/testLibPQ/blob/master/testlibpq.c
Is this possible to change something (I really don't know what or
where) in the jdbc driver
to get more direct aproach? (if that's make any sense to you guys...)
Best regards,
vinnix
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
