Обсуждение: BUG #6530: intarray documentation could do with a warning about operators

The following bug has been logged on the website:

Bug reference:      6530
Logged by:          Kasper Sandberg
Email address:      kontakt@sandberg-consult.dk
PostgreSQL version: 9.1.3
Operating system:   Debian squeeze
Description:=20=20=20=20=20=20=20=20

Hello.

I recently had a problem with array operators && and @> on my gin index, it
failed. Friendly people on #postgresql helped me track down the root cause -
intarray, which i had just imported into my schema. I think it would be nice
if the documentation for intarray on the documentations page had a short
warning about this, so people can import into other schemas if they need to
use the default array operators.

Thanks.

On Tue, Mar 13, 2012 at 1:12 PM,  <kontakt@sandberg-consult.dk> wrote:
> The following bug has been logged on the website:
>
> Bug reference: =A0 =A0 =A06530
> Logged by: =A0 =A0 =A0 =A0 =A0Kasper Sandberg
> Email address: =A0 =A0 =A0kontakt@sandberg-consult.dk
> PostgreSQL version: 9.1.3
> Operating system: =A0 Debian squeeze
> Description:
>
> Hello.
>
> I recently had a problem with array operators && and @> on my gin index, =
it
> failed. Friendly people on #postgresql helped me track down the root caus=
e -
> intarray, which i had just imported into my schema. I think it would be n=
ice
> if the documentation for intarray on the documentations page had a short
> warning about this, so people can import into other schemas if they need =
to
> use the default array operators.
>
> Thanks.

We do have this:

  <para>
   The operators <literal>&&</>, <literal>@></> and
   <literal><@</> are equivalent to <productname>PostgreSQL</>'s built-in
   operators of the same names, except that they work only on integer arrays
   that do not contain nulls, while the built-in operators work for any arr=
ay
   type.  This restriction makes them faster than the built-in operators
   in many cases.
  </para>

But maybe some more explicit warning is needed.  Not sure exactly what.

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:
> We do have this:

>   <para>
>    The operators <literal>&&</>, <literal>@></> and
>    <literal><@</> are equivalent to <productname>PostgreSQL</>'s built-in
>    operators of the same names, except that they work only on integer arrays
>    that do not contain nulls, while the built-in operators work for any array
>    type.  This restriction makes them faster than the built-in operators
>    in many cases.
>   </para>

> But maybe some more explicit warning is needed.  Not sure exactly what.

I think the gripe is basically that, while these operators might be
equivalent to the built-in ones as far as results go, they are not
equivalent in terms of their ability to match to indexes.  But not
sure how we turn that observation into useful documentation.

            regards, tom lane

yes, I could not figure out why my GIN index was not used, this is what
i meant.

On 09/04/12 18:16, Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com>  writes:
>> We do have this:
>>    <para>
>>     The operators<literal>&&</>,<literal>@></>  and
>>     <literal><@</>  are equivalent to<productname>PostgreSQL</>'s built-in
>>     operators of the same names, except that they work only on integer arrays
>>     that do not contain nulls, while the built-in operators work for any array
>>     type.  This restriction makes them faster than the built-in operators
>>     in many cases.
>>    </para>
>> But maybe some more explicit warning is needed.  Not sure exactly what.
> I think the gripe is basically that, while these operators might be
> equivalent to the built-in ones as far as results go, they are not
> equivalent in terms of their ability to match to indexes.  But not
> sure how we turn that observation into useful documentation.
>
>             regards, tom lane


--
Kasper Sandberg
Sandberg Enterprises
+45 51944242
http://www.sandbergenterprises.dk