Dmitry Tkach wrote:> Fernando Nasser wrote:
>
>> Darin Ohashi wrote:
>>
>>>> There is no technical reason why sql prepare cannot support "IN ?"
>>>> If it is not supported by the backend at the moment should not
>>>> affect the general decision of whether or not having such a feature
>>>> is useful to have in the jdbc driver or not.
>>>>
>>
>> Unfortunately it does. How can we justify a feature that only works
>> when we are simulating prepared statements and fails when we are using
>> the real PREPARED statements as provided by the server?
>
>
> It should not *fail* of course.
> The driver should take care of it. If the backend does not support
> PREPARE/EXECUTE with sets as parameters, the driver should know about
> that, and handle it as a special case
>
You are suggesting that when the driver detects that one of the parameters is
the value for an IN clause (i.e., an <in values list>) it should abstain to use
the server prepared statements and falls back to use the client emulation
instead? Isn't that a little unsettling for the user, who is expecting that
the prepared statements are being handled by the server?
You understand, also, that we would have to keep the client emulation code
around with all complications and limitations that it has (for not being in the
server)even when all supported backend versions have PREPARED implemented.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
