| From: | Dmitry Tkach <dmitry(at)openratings(dot)com> |
|---|---|
| To: | Fernando Nasser <fnasser(at)redhat(dot)com> |
| Cc: | Darin Ohashi <DOhashi(at)maplesoft(dot)com>, 'Oliver Jowett' <oliver(at)opencloud(dot)com>, Kim Ho <kho(at)redhat(dot)com>, Barry Lind <blind(at)xythos(dot)com>, pgsql-jdbc-list <pgsql-jdbc(at)postgresql(dot)org>, Dave Cramer <Dave(at)micro-automation(dot)net> |
| Subject: | Re: IN clauses via setObject(Collection) [Was: Re: Prepare |
| Date: | 2003-07-21 20:14:33 |
| Message-ID: | 3F1C49A9.3010101@openratings.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
>
> 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?
Yep. It is indeed a little unsetting... Much *less* unsetting though
then just not being able to do that at all...
>
>
> 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.
>
>
Well... yes. Unless all supported backend versions will also have
PREPARE implemented to understand sets...
The only alternative is to have this code "with all complications and
limitantions" be kept and maintain by every user on their own...
Dima
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Darin Ohashi | 2003-07-21 20:20:45 | Re: IN clauses via setObject(Collection) [Was: Re: Prepare |
| Previous Message | Fernando Nasser | 2003-07-21 19:58:36 | Re: IN clauses via setObject(Collection) [Was: Re: Prepare |