From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dawid Kuroczko" <qnex42(at)gmail(dot)com> |
Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: PostgreSQL 8.2 Bug in casting varchar to int in SELECT ... WHERE IN ( ... ) |
Date: | 2007-10-20 03:05:24 |
Message-ID: | 29692.1192849524@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Dawid Kuroczko" <qnex42(at)gmail(dot)com> writes:
> What troubles me here is that surprise factor is unusally high here.
> While I understand mechanics why IN (1) works while IN (1,2) does not,
> I think random developers are going to be confused.
If you're not testing against 8.3 then this argument doesn't carry much
weight. 8.3 will reject *both* cases in the examples you've mentioned.
> PS: I wonder why explicitly using IN (ARRAY[...]) works.
Um, it does not work AFAICS:
regression=# select 'foo'::varchar in (array[1,2,3]);
ERROR: operator does not exist: character varying = integer[]
LINE 1: select 'foo'::varchar in (array[1,2,3]);
^
HINT: No operator matches the given name and argument type(s). You may need to add explicit type casts.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-10-20 08:09:01 | Re: BUG #3682: Incomplete database restore |
Previous Message | Gary Chambers | 2007-10-20 03:04:27 | BUG #3682: Incomplete database restore |