Re: the IN clause saga
От | Felipe Schnack |
---|---|
Тема | Re: the IN clause saga |
Дата | |
Msg-id | 20030722121244.7ffa575f.felipes@ritterdosreis.br обсуждение исходный текст |
Ответ на | Re: the IN clause saga (Fernando Nasser <fnasser@redhat.com>) |
Ответы |
Re: the IN clause saga
(Barry Lind <blind@xythos.com>)
Re: the IN clause saga (peter royal <peter.royal@pobox.com>) |
Список | pgsql-jdbc |
Am I the only the only one who doesn't like the idea of the driver parsing SQL statements (to check if there is a IN clause) On Tue, 22 Jul 2003 10:41:22 -0400 Fernando Nasser <fnasser@redhat.com> wrote: > Oliver Jowett wrote: > > On Tue, Jul 22, 2003 at 09:05:45AM -0400, Fernando Nasser wrote: > > > >>Thanks for summarizing it Oliver. > >> > >>I've asked Tom Lane about the backend behavior and he informed me that: > >> > >>1) 7.4 backends do support parameters in the IN predicate, as ($1, $2, > >>$3) (i.e., our (?, ?, ?) syntax). > >> > >>2) 7.4 backends have a PostgreSQL specific extension that allows you to > >>fill the IN predicate with a list: ($1) (i.e., our (?) ). One has to > >>pass a PostgreSQL array, like integer[] to fill the list. Note that the > >>parenthesis is already in place, it is not generated by the ? expansion. > > > > > > I assume this is only when you're doing a PREPARE/EXECUTE? > > > > yes. > > > > >>The feature 2 in 7.4 backends is of limited use as the planner does not > >>know about the list, so the generated plan will not be as good as if you > >>pass the list with fixed values since the beginning. But an improvement > >>for this can be attempted for 7.5. > > > > > > Hm, then it sounds like the right solution is to have setArray() expand as > > the guts of an IN clause when the backend is <7.4 or server prepares are > > off, and the parameter is in a query of the form "... IN (?)", and as a > > normal array otherwise. > > > > That is _exactly_ what I am proposing (option 2 of your summary) > > > > -- > Fernando Nasser > Red Hat Canada Ltd. E-Mail: fnasser@redhat.com > 2323 Yonge Street, Suite #300 > Toronto, Ontario M4P 2C9 > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- /~\ The ASCII Felipe Schnack (felipes@ritterdosreis.br) \ / Ribbon Campaign Analista de Sistemas X Against HTML Cel.: 51-91287530 / \ Email! Linux Counter #281893 Centro Universitário Ritter dos Reis http://www.ritterdosreis.br ritter@ritterdosreis.br Fone: 51-32303341
В списке pgsql-jdbc по дате отправления: