Darin Ohashi wrote:
>If I could throw in a question from the sidelines...
>
>Is this something that a PreparedStatement should be able to handle, in general?
>
>
I think yes.
Depends on your definiton of "in general", of course,
Where I come from, at least "in general", the PreparedStatement should
be able to handle *everything* you can do with sql.
>
>
>With a PreparedStatement that gets precompiled, will a substitution like this
>work?
>
Depends on the implementation...
If the backend doesn't support it, the driver should take care of
working around that
(e.g. by switching to 'non-precompiled' version in this case) until the
backend is able to support it (I don't see any reason why it just cannot
be done theoretically).
> Do other JDBC drivers support this kind of substitution?
>
Yes. They do (at least, the ones I worked with do).
>
>It looks like you are exploiting a bug (or perhaps an out of spec behaviour) in
>the JDBC. If that is the case, then I don't have much sympathy for you losing
>this functionality.
>
I am not going to lose it :-)
Thanks to the driver being opensource I have control over what I am
going to lose :-)
>
>Instead of creating your own driver, why not just subclass Statement into
>something that looks like a PreparedStatement but just glues strings together?
>
Ummm... because it already exists? That's what postgres
PreparedStatement does (by default in 7.3, and always in previous
versions)...
>That sounds like what you want anyway. It also seems like a much eaiser task,
>especially for long term maintainance.
>
>
No, that's not what I want...
What I want is an abstraction of the implementation-specific details,
that lets me effectively execute sql queries.
If it can precompile my query, I want it to precompile it. If it cannot,
I can live with that (for a while).
I just don't want to *know* what it is doing.
Dima