From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: php.pl.prices@gmail.com, pgsql-docs@lists.postgresql.org
Subject: Re: @> (contains)
In-reply-to: 
 <CAKFQuwads-TKniO0=EYYG+AQkyxmCbOCD5jPXjjR5ZBk2dyDYg@mail.gmail.com>
References: <156614120484.1310.310161642239149585@wrigleys.postgresql.org>
 <CAKFQuwads-TKniO0=EYYG+AQkyxmCbOCD5jPXjjR5ZBk2dyDYg@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Sun, 18 Aug 2019 09:19:58 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10212.1569257796.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Sep 2019 12:56:36 -0400
Message-ID: <10213.1569257796@sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sun, Aug 18, 2019 at 8:53 AM PG Doc comments form <noreply@postgresql=
.org>
>> Noticed strange thin with @>
>> Query "select '{1,2}'::int[] @> '{1,2,2,2,2,2,2,2}'::int[]" returns tru=
e,
>> but first array contains even less elements then second.
>> I think it's a bug in "contains" logic, but don't know where to submit =
it.

> Its a valid interpretation of "contains", for this purpose each array is
> treated like a set (ignoring the cardinality of elements, and overall
> dimensionality), but it needs to be documented as behaving that way on t=
hat
> page.

Done now.

			regards, tom lane