| From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dmitry Tkach <dmitry(at)openratings(dot)com>, Fernando Nasser <fnasser(at)redhat(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:11:32 |
| Message-ID: | 20030722151132.GP11354@opencloud.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
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.
-O
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Felipe Schnack | 2003-07-22 15:12:44 | Re: the IN clause saga |
| Previous Message | Felipe Schnack | 2003-07-22 15:05:45 | Re: patch: tiny patch to correct stringbuffer size estimate |