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

On Wed, Aug 26, 2020 at 07:19:09PM -0400, Tom Lane wrote:
> With one eye on the PDF width issue, I propose that we not draw
> the distinction, but just list all the relevant operators for each
> opclass (its native ones, plus the applicable "loose" operators).
> Then we only need two columns, opclass and operators.

Indeed, removing the types makes sense if we list them with the
operators. I have been looking at your suggestions, and adding a
space before the first parenthesis where the types are listed sounds
good to me, but I am not sure that it is a good idea to add spaces
between each type. Looking at the pdf produced, I think that we
should also drop entirely colspec for the BRIN table as it gets much
small in width once the data type column is removed. I also looked at
rowsep for the PDF, and I tend to prefer the version where we separate
each cell for the operator, as a matter of readability.

This leads me to the updated version attached. BRIN has 29 different
opclasses, visibly.
--
Michael