Hello Rick,
thanks for your replies!

> In order to support executing unprepared SQL, prepared statements
> are converted to a String so both prepared and "free-form" SQL
> gets passed to statementExecutor(String sqlStatement)

Kind of. It's not because of supporting one type of SQL statements
or/after the other, it's because of supporting both types with a
single 'statementExecutor()' method.

> What if instead all Strings get prepared by

statementPreparer(String sqlStatement)

> and then both types of statements just get executed

Well that's somehow an improvement suggestion for the SQL execution:
but how can you pass a prepared statement to the statementPreparer()
method, when you cannot convert this very prepared statement to String?

> I vote for keeping it vendor specific. I access all vendor stuff
> within wrappers anyway

As I have mentioned in my previous reply, the idea for solving it
vendor-specific due to standardization concerns seems quite
reasonable. I have asked for the described feature in order to be able
to provide a more general-purpose solution, which will be nice for the
end users.


- Roman wrote:

> > Please fill the feature request at SourceForge.net, so we
> > do not forget it before the next RC and/or final release.
> > Just type few words - Yahoo might decide to remove their
> > message database.

- me:

> Okay, I'll try to formulate something as a description.

Here it is:
http://sourceforge.net/tracker/index.php?func=detail&aid=1283213&group_id=130139&atid=718321