Re: IN clauses via setObject(Collection) [Was: Re: Prepare
От | Fernando Nasser |
---|---|
Тема | Re: IN clauses via setObject(Collection) [Was: Re: Prepare |
Дата | |
Msg-id | 3F1C45EC.30207@redhat.com обсуждение исходный текст |
Ответ на | Re: IN clauses via setObject(Collection) [Was: Re: Prepare (Darin Ohashi <DOhashi@maplesoft.com>) |
Ответы |
Re: IN clauses via setObject(Collection) [Was: Re: Prepare
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: