Re: Document "59.2. Built-in Operator Classes" have a clerical error?

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Aug 03, 2020 at 03:14:56PM +0800, osdba wrote:
>> "range_opsany range type&& &> &< >> << <@ -|- = @> @>"， exist double "@>"，
>> Should be "<@ @>" ?

> Indeed, this needs to be improved. Another issue on the same page is
> that point_ops lists the same operator three times, <@. Other index
> pages don't seem to have any inconsistencies, fortunately.

psql's handy new \dAo query clarifies things a bit:

regression=# \dAo gist range_ops
List of operators of operator families
AM | Operator family | Operator | Strategy | Purpose
------+-----------------+-------------------------+----------+---------
gist | range_ops | <<(anyrange,anyrange) | 1 | search
gist | range_ops | &<(anyrange,anyrange) | 2 | search
gist | range_ops | &&(anyrange,anyrange) | 3 | search
gist | range_ops | &>(anyrange,anyrange) | 4 | search
gist | range_ops | >>(anyrange,anyrange) | 5 | search
gist | range_ops | -|-(anyrange,anyrange) | 6 | search
gist | range_ops | @>(anyrange,anyrange) | 7 | search
gist | range_ops | <@(anyrange,anyrange) | 8 | search
gist | range_ops | =(anyrange,anyrange) | 18 | search
gist | range_ops | @>(anyrange,anyelement) | 16 | search
(10 rows)

regression=# \dAo gist point_ops
List of operators of operator families
AM | Operator family | Operator | Strategy | Purpose
------+-----------------+-------------------+----------+----------
gist | point_ops | <<(point,point) | 1 | search
gist | point_ops | >>(point,point) | 5 | search
gist | point_ops | ~=(point,point) | 6 | search
gist | point_ops | <^(point,point) | 10 | search
gist | point_ops | >^(point,point) | 11 | search
gist | point_ops | <->(point,point) | 15 | ordering
gist | point_ops | <@(point,box) | 28 | search
gist | point_ops | <@(point,circle) | 68 | search
gist | point_ops | <@(point,polygon) | 48 | search
(9 rows)

So I don't think it's a clerical error, but certainly showing these
operators this way is none too helpful. Perhaps including the input types
in this table (and its siblings elsewhere) would be a good thing.

(Looking at these, I'm reminded anew that the sort ordering used by \dAo
is still questionable ...)

regards, tom lane