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

On Tue, Aug 25, 2020 at 06:17:28PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> (With the non-website stylesheet, as in the screenshot you showed, the
>> table looks somewhat crammed and visually unappealing; but the website
>> stylesheet looks pleasing enough. Screenshot attached.)

Right, STYLE=website.

> I wonder if it would look better if we suppress the horizontal rules
> between the operator names within a cell. IIRC, it's possible to do
> that, though the exact incantation isn't coming to mind right now.

I would imagine that rowsep=0 for a given <entry> can do that:
https://tdg.docbook.org/tdg/4.5/entry.html
However, it does not make a difference if I use the default style or
the website style. I may be missing something with the stylesheet
though?

>> I suppose a commit would change all the index AMs where we document this
>> kind of thing.
>
> Yeah, we should make all these sorts of tables consistent.

Of course, just wanted to make sure that we agree on the layer before
spending more time on that as shaping all the tables correctly is a
lot of work. And GIN is the smallest one.

One thing to note about the BRIN table is that we have never
documented from the start any of the operators working across multiple
types. For example, we only have 5 operators listed for each one of
int2/int4/int8, timestamptz/timestamp or real/float, but these are
listed with incorrect names and they miss a bunch of other operators
able to handle combinations of (int2,int4), etc. So I have fixed the
table so as all the operators are listed, grouping together ints,
timestamps and reals, as \dAo says. Now there could be also an
argument to stick with simplicity and list only the operators of one
single type, reducing the size of the table for BRIN. But that would
be incorrect with the catalogs, and the attached classifies all
operators in alphabetical order. (Switching to the original list is
not complicated as that would be just removing code from the attached,
so I took the complicated path for now.)
--
Michael