From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Why does =ANY(<array>) need an extra cast when used |
Date: | 2004-08-23 15:04:28 |
Message-ID: | 20040823075510.H6667@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 23 Aug 2004, Frank van Vugt wrote:
> The following works :
>
> db=# select 1 = ANY ('{1,2,3}'::int[]);
> ?column?
> ----------
> t
> (1 row)
>
>
> This doesn't :
>
> db=# select 1 = ANY (select '{1,2,3}'::int[]);
> ERROR: operator does not exist: integer = integer[]
> HINT: No operator matches the given name and argument type(s). You may need
> to add explicit type casts.
>
> Using an extra case, the above can easily be made to work :
>
> db=# select 1 = ANY ((select '{1,2,3}'::int[])::int[]);
> ?column?
> ----------
> t
> (1 row)
>
>
> I'm just wondering why the array returned by the inner select is not casted by
> ANY() automagically?
Barring the cast syntax and such, the first and last query would I believe
be illegal in SQL92/99, so we defined useful behavior for them for this
case. The second query looks to me to be of the form = ANY (table
subquery) which already had defined behavior by spec. Changing it to act
like the first or last would break that spec behavior.
From | Date | Subject | |
---|---|---|---|
Next Message | borajetta | 2004-08-23 15:35:54 | Re: ERROR: duplicate key violates unique constraint "pg_class_oid_index" |
Previous Message | Bruce Momjian | 2004-08-23 15:04:11 | Re: Unsupported 3rd-party solutions (Was: Few questions |