I understand now - thank you. It still rubs me the wrong way that both a OP
b and a not OP b can be equal - STL would go berserk. I guess it was not so
clear to me that ANY / ALL aren't pure functions, more of a control
structure .
Thank you,
Anton.
On Fri, May 15, 2015 at 1:02 AM, David G. Johnston <
david.g.johnston@gmail.com> wrote:
> On Thu, May 14, 2015 at 10:12 AM, <udtelco@gmail.com> wrote:
>
>> The following bug has been logged on the website:
>>
>> Bug reference: 13289
>> Logged by: Anton
>> Email address: udtelco@gmail.com
>> PostgreSQL version: 9.3.2
>> Operating system: Solaris 11.2
>> Description:
>>
>> select ('2' !=3D any('{2,3}')) , ('2' =3D any('{2,3}'))
>>
>> When !=3D (or <>) operator is applied to any() , results are wrong. Ther=
eby,
>> you have a situation where x =3D y AND x !=3D y both evaluating as true.
>>
>
> =E2=80=8B=E2=80=8BAs Tom said.=E2=80=8B
>
> =E2=80=8BAnd what is "y" in your argument?=E2=80=8B
>
> This is shorthand for:
>
> ('2' !=3D '2' OR '2' !=3D '3')=E2=80=8B, ('2' =3D '2' OR '2' =3D '3')
>
> =E2=80=8B=E2=80=8BIf you define "y" as the expression "any('{2,3}')" then=
it is not even
> of the same type as the scalar '2' so a literal comparison is undefined.
> Therefore, PostgreSQL treats it as syntactic sugar for the compound boole=
an
> expression (x op y[1] OR x op y[2] OR ...)
>
> David J.
>
>