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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Bruce Momjian <bruce(at)momjian(dot)us>, osdba <mailtch(at)163(dot)com>, pgsql-docs(at)postgresql(dot)org, jkatz(at)postgresql(dot)org
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?
Date: 2020-08-28 01:12:39
Message-ID: 3379567.1598577159@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2020-Aug-27, Michael Paquier wrote:
>> This leads me to the updated version attached. BRIN has 29 different
>> opclasses, visibly.

> I checked both HTML and PDF and it looks good to me to commit.

I did not verify that the correct operators are listed, but visually
it looks OK.

One thing I've noted in working with this stuff is that (at least for me)
HTML seems to default to valign=center while PDF defaults to valign=top.
You can see that in these tables in the positioning of the opclass names.
For myself, valign=center looks better in these cases so I'd suggest
adding <colspec>s to force it that way. Or, if you like valign=top,
we should do that --- but it ought to be consistent across output formats.

> As a subsequent improvement we could discuss tweak the stylesheets to
> change the column widths in PDF, but I don't think we need to stall this
> patch for that, since it's a much smaller issue IMV.

Yeah, I think some fooling with the column widths could improve the PDF
results, but it's a minor point.

regards, tom lane

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2020-08-28 01:16:51 Re: small clairifcation
Previous Message PG Doc comments form 2020-08-27 16:18:31 small clairifcation