Re: binary patch problems - Mailing list pgsql-jdbc

Tom Lane <tgl@sss.pgh.pa.us> Monday 19 of September 2011 16:47:12
> Mikko Tiihonen <mikko.tiihonen@nitorcreations.com> writes:
> > On 09/19/2011 01:11 PM, Bodor Andras wrote:
> >> Why don't you set prepareThreshold to 0 for your test cases?
> >> In this case parameter passing starts immediately for the
> >> prepared statement, and ForceBinaryTransfers can be dropped.
> >
> > AbstractJdbc2Statement:
> >      public boolean isUseServerPrepare() {
> >
> >          return (preparedQuery != null && m_prepareThreshold != 0 &&
> >          m_useCount + 1 >= m_prepareThreshold);
> >
> >      }
> >
> > If I read the above correctly then prepareThreshold of 0 disables
> > prepared statements.
>
> But "1" would do what you want, no?
>
> FWIW, I'm hoping that this entire business of delaying the server-side
> prepare will be obsolete as of 9.2.  There is already code committed in
> HEAD that allows "prepared" statements to be re-planned for each new set
> of parameter values, with a somewhat-informed choice of whether and when
> to switch over to the traditional generic-plan approach.  It needs
> tweaking for performance still, no doubt, but there is not going to be a
> reason for the driver to do this anymore.
>
> Obviously that's not much use for solving your immediate problem, but it
> might lead you to conclude that putting a large amount of effort into
> improving this mechanism would be a dead end.
>
>             regards, tom lane

The whole logic about this was, because PreparedStatement are not used in Java
to be prepared in means of database server. It's normal technique to write
even one shoot statements
ps = conn.prepareStatemn(SELECT * FROM foo where id = ?)
This simple techinique makes code more simple and saftly; it prevents SQL
injection, as well no one need to care about proper data escaping. So If
someone uses statements once, there may be no need to parsing plan for this
(prove why server should do this for you by invoking it 5 times).
As side effect of this popular concept many J2EE servers provides new pool,
with ecah connection (connection are pooled), you get statement pool, so web-
based and J2EE environments (which are mainly single-request based) may with
no effort form developer side use benefits of preparation.

The PG "one shot" statements will not make this obsolete
1) Driver will be backward compatible (it's still supports 7.x editions)
2) Above problem will be still present.
3) Java perpared statements uses ? inseted of positional parameters, so driver
need to parse query in any way.

Regards
Radek
http://www.softperience.eu/