Re: the IN clause saga

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

In response to

Responses

Browse pgsql-jdbc by date

  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