Remove contrib/intarray's definitions of the <@ and @> operators, so that they

don't cause confusion with the built-in anyarray versions of those operators.
Adjust the module's index opclasses to support the built-in operators in place
of the private ones.

The private implementations are still available under their historical
names @ and ~, so no functionality is lost.  Some quick testing suggests
that they offer no real benefit over the core operators, however.

Per a complaint from Rusty Conover.

diff --git a/contrib/intarray/_int.sql.in b/contrib/intarray/_int.sql.in
index 9f91a65eec717435e7c9c1853c4ba2bfa6c50211..93930b559d501d3b228509c79a94b5f920962a0a 100644 (file)
--- a/contrib/intarray/_int.sql.in
+++ b/contrib/intarray/_int.sql.in
@@ -1,4 +1,4 @@
-/* $PostgreSQL: pgsql/contrib/intarray/_int.sql.in,v 1.29 2009/03/25 22:19:01 tgl Exp $ */
+/* $PostgreSQL: pgsql/contrib/intarray/_int.sql.in,v 1.30 2009/04/05 00:40:35 tgl Exp $ */
 
 -- Adjust this setting to control where the objects get created.
 SET search_path = public;
@@ -152,23 +152,23 @@ CREATE OPERATOR && (
 -- JOIN = neqjoinsel
 --);
 
-CREATE OPERATOR @> (
-   LEFTARG = _int4,
-   RIGHTARG = _int4,
-   PROCEDURE = _int_contains,
-   COMMUTATOR = '<@',
-   RESTRICT = contsel,
-   JOIN = contjoinsel
-);
+--CREATE OPERATOR @> (
+-- LEFTARG = _int4,
+-- RIGHTARG = _int4,
+-- PROCEDURE = _int_contains,
+-- COMMUTATOR = '<@',
+-- RESTRICT = contsel,
+-- JOIN = contjoinsel
+--);
 
-CREATE OPERATOR <@ (
-   LEFTARG = _int4,
-   RIGHTARG = _int4,
-   PROCEDURE = _int_contained,
-   COMMUTATOR = '@>',
-   RESTRICT = contsel,
-   JOIN = contjoinsel
-);
+--CREATE OPERATOR <@ (
+-- LEFTARG = _int4,
+-- RIGHTARG = _int4,
+-- PROCEDURE = _int_contained,
+-- COMMUTATOR = '@>',
+-- RESTRICT = contsel,
+-- JOIN = contjoinsel
+--);
 
 -- obsolete:
 CREATE OPERATOR @ (
@@ -365,8 +365,8 @@ CREATE OPERATOR CLASS gist__int_ops
 DEFAULT FOR TYPE _int4 USING gist AS
    OPERATOR    3   &&,
    OPERATOR    6   = (anyarray, anyarray),
-   OPERATOR    7   @>,
-   OPERATOR    8   <@,
+   OPERATOR    7   @> (anyarray, anyarray),
+   OPERATOR    8   <@ (anyarray, anyarray),
    OPERATOR    13  @,
    OPERATOR    14  ~,
    OPERATOR    20  @@ (_int4, query_int),
@@ -442,8 +442,8 @@ FOR TYPE _int4 USING gist
 AS
    OPERATOR    3   &&,
    OPERATOR    6   = (anyarray, anyarray),
-   OPERATOR    7   @>,
-   OPERATOR    8   <@,
+   OPERATOR    7   @> (anyarray, anyarray),
+   OPERATOR    8   <@ (anyarray, anyarray),
    OPERATOR    13  @,
    OPERATOR    14  ~,
    OPERATOR    20  @@ (_int4, query_int),
@@ -473,8 +473,8 @@ FOR TYPE _int4 USING gin
 AS
    OPERATOR    3   &&,
    OPERATOR    6   = (anyarray, anyarray),
-   OPERATOR    7   @>,
-   OPERATOR    8   <@,
+   OPERATOR    7   @> (anyarray, anyarray),
+   OPERATOR    8   <@ (anyarray, anyarray),
    OPERATOR    13  @,
    OPERATOR    14  ~,
    OPERATOR    20  @@ (_int4, query_int),

diff --git a/contrib/intarray/uninstall__int.sql b/contrib/intarray/uninstall__int.sql
index 5346bddc7528920de582b4d2242b45c5dfadce93..42721ed2fb09c80107d2b2230b83c4e628ec673e 100644 (file)
--- a/contrib/intarray/uninstall__int.sql
+++ b/contrib/intarray/uninstall__int.sql
@@ -1,4 +1,4 @@
-/* $PostgreSQL: pgsql/contrib/intarray/uninstall__int.sql,v 1.10 2009/03/25 22:19:01 tgl Exp $ */
+/* $PostgreSQL: pgsql/contrib/intarray/uninstall__int.sql,v 1.11 2009/04/05 00:40:35 tgl Exp $ */
 
 -- Adjust this setting to control where the objects get created.
 SET search_path = public;
@@ -91,10 +91,6 @@ DROP FUNCTION icount(_int4);
 
 DROP FUNCTION intset(int4);
 
-DROP OPERATOR <@ (_int4, _int4);
-
-DROP OPERATOR @> (_int4, _int4);
-
 DROP OPERATOR ~ (_int4, _int4);
 
 DROP OPERATOR @ (_int4, _int4);

diff --git a/doc/src/sgml/intarray.sgml b/doc/src/sgml/intarray.sgml
index ddf74218991448810f12bf429e911a3f96c03efe..2e77b57de3eea1f8f40c64cc79068504bfe1b390 100644 (file)
--- a/doc/src/sgml/intarray.sgml
+++ b/doc/src/sgml/intarray.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  intarray
@@ -134,12 +134,12 @@
       overlap — true if arrays have at least one common element
      
      
-      int[] @> int[]
+      int[] @ int[]
       boolean
       contains — true if left array contains right array
      
      
-      int[] <@ int[]
+      int[] ~ int[]
       boolean
       contained — true if left array is contained in right array
      
@@ -203,11 +203,13 @@
   
 
   
-   (Before PostgreSQL 8.2, the containment operators @> and <@ were
-   respectively called @ and ~.  These names are still available, but are
-   deprecated and will eventually be retired.  Notice that the old names
-   are reversed from the convention formerly followed by the core geometric
-   datatypes!)
+   The containment operators @ and ~ are functionally
+   equivalent to PostgreSQL's built-in operators
+   @> and <@, respectively, except that
+   @ and ~ work only on integer arrays.  These
+   operator names are deprecated and will eventually be retired.  (Notice that
+   these names are reversed from the convention formerly followed by the core
+   geometric datatypes!)
   
 
   
@@ -228,10 +230,10 @@
 
   
    intarray provides index support for the
-   &&, @>, <@,
-   and @@ operators, as well as regular array equality.
-   The implementation uses an RD-tree data structure with
-   built-in lossy compression.
+   &&, @, ~,
+   and @@ operators, as well as regular array equality
+   and the built-in @> and <@ operators
+   (when used on integer arrays).
   
 
   
@@ -241,11 +243,13 @@
    gist__intbig_ops uses a larger signature and is more
    suitable for indexing large data sets (i.e., columns containing
    a large number of distinct array values).
+   The implementation uses an RD-tree data structure with
+   built-in lossy compression.
   
 
   
    There is also a non-default GIN operator class
-   gin__int_ops.
+   gin__int_ops supporting the same operators.
   
 
   
@@ -304,7 +308,7 @@ SELECT message.mid FROM message WHERE message.sections @@ '1&2'::query_int;
   Authors
 
   
-   All work was done by Teodor Sigaev (teodor@stack.net) and
+   All work was done by Teodor Sigaev (teodor@sigaev.ru) and
    Oleg Bartunov ([email protected]). See
     for
    additional information. Andrey Oktyabrski did a great work on adding new