Re: the IN clause saga - Mailing list pgsql-jdbc

From Fernando Nasser
Subject Re: the IN clause saga
Date
Msg-id 3F1D4D12.3000709@redhat.com
Whole thread Raw
In response to the IN clause saga  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: the IN clause saga
List pgsql-jdbc
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


pgsql-jdbc by date:

Previous
From: Fernando Nasser
Date:
Subject: Re: the IN clause saga
Next
From: Oliver Jowett
Date:
Subject: Re: patch: tiny patch to correct stringbuffer size estimate