Re: @> (contains)

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: php(dot)pl(dot)prices(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: @> (contains)
Date: 2019-08-18 16:19:58
Message-ID: CAKFQuwads-TKniO0=EYYG+AQkyxmCbOCD5jPXjjR5ZBk2dyDYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Sun, Aug 18, 2019 at 8:53 AM PG Doc comments form <noreply(at)postgresql(dot)org>
wrote:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.6/functions-array.html
> Description:
>
> Hi.
> Noticed strange thin with @>
> Query "select '{1,2}'::int[] @> '{1,2,2,2,2,2,2,2}'::int[]" returns true,
> 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 that
page. I don't see that its documented anywhere for that matter. The
source code documents that dimensions are ignored but is silent on
duplication of elements:

array_contain_compare:
/*-----------------------------------------------------------------------------
* array overlap/containment comparisons
* These use the same methods of comparing array elements as array_eq.
* We consider only the elements of the arrays, ignoring dimensionality.
*----------------------------------------------------------------------------
*/

David J.

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Liudmila Mantrova 2019-08-19 14:12:12 minor doc fixes for REL_12_STABLE
Previous Message PG Doc comments form 2019-08-18 15:13:24 @> (contains)