From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Fernando Nasser <fnasser(at)redhat(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org, Barry Lind <blind(at)xythos(dot)com>, Dave Cramer <Dave(at)micro-automation(dot)net> |
Subject: | Re: the IN clause saga |
Date: | 2003-07-22 14:40:35 |
Message-ID: | 20030722144034.GJ11354@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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?
> 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.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Fernando Nasser | 2003-07-22 14:41:22 | Re: the IN clause saga |
Previous Message | Dmitry Tkach | 2003-07-22 14:40:15 | Re: the IN clause saga |