Re: the IN clause saga

From: Fernando Nasser <fnasser(at)redhat(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dmitry Tkach <dmitry(at)openratings(dot)com>, 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 15:16:06
Message-ID: 3F1D5536.6020700@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Oliver Jowett wrote:
> On Tue, Jul 22, 2003 at 10:51:51AM -0400, Tom Lane wrote:
>
>
>>Fernando Nasser <fnasser(at)redhat(dot)com> writes:
>>
>>>PREPARE tststmt (integer[]) AS SELECT * from testmetadata where id IN (?);
>>>PREPARE tststmt (integer, integer) AS SELECT * from testmetadata where id IN (?, ?);
>>>all give parsing errors.
>>
>
>>I would not expect the first case to work, since it violates the plain
>>meaning of IN. But Joe Conway has implemented some non-SQL syntax to
>>handle that in 7.4:
>>
>>regression=# prepare zz(int[]) as select * from tenk1 where unique1 = ANY ($1);
>>PREPARE
>>regression=# execute zz(ARRAY[42,66]);
>
>
> Ouch. That syntax is going to be messy to transform into an IN clause for
> <7.4 backends.
>

Remember we will already have to know that we are handling the <in
values list> clause (i.e. it is a " IN (?)'), so we can very well
special case the expansion of the array.

But it will be much better on 7.4 and V3, I agree.

--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Barry Lind 2003-07-22 15:53:36 Re: Patch applied for SQL Injection vulnerability for setObject(int, Object, int)
Previous Message Fernando Nasser 2003-07-22 15:15:06 Re: the IN clause saga