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
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 |