Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1kB3kL-0005sH-AY
	for pgsql-docs@arkaria.postgresql.org; Wed, 26 Aug 2020 22:18:21 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1kB3kI-0007zv-JS
	for pgsql-docs@arkaria.postgresql.org; Wed, 26 Aug 2020 22:18:18 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1kB3kI-0007zn-DV
	for pgsql-docs@lists.postgresql.org; Wed, 26 Aug 2020 22:18:18 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1kB3kB-0005S8-JY; Wed, 26 Aug 2020 22:18:17 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 07QMHxE22983368;
	Wed, 26 Aug 2020 18:17:59 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Michael Paquier <michael@paquier.xyz>, Bruce Momjian <bruce@momjian.us>,
        osdba <mailtch@163.com>, pgsql-docs@postgresql.org,
        jkatz@postgresql.org
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?
In-reply-to: <20200826215801.GA30013@alvherre.pgsql>
References: <20200826215801.GA30013@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Wed, 26 Aug 2020 17:58:01 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2983366.1598480279.1@sss.pgh.pa.us>
Date: Wed, 26 Aug 2020 18:17:59 -0400
Message-ID: <2983367.1598480279@sss.pgh.pa.us>
List-Id: <pgsql-docs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-docs@lists.postgresql.org>
List-Owner: <mailto:pgsql-docs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-docs>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-Aug-26, Michael Paquier wrote:
>> 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 have no idea there.  Maybe Jon Katz (CCed) could help you to find an
> answer to that question.

Yeah, I can't make it work as documented either.  Weird --- I wonder if
our stylesheets are messing that up?  It *does* work in PDF output.

Speaking of PDF output, we have a fair amount of work to do to make these
tables render sanely in PDF.  As the patch stands, it reintroduces a bunch
of "exceed the available area" complaints.  Partly that is because, in the
interests of making the old contents fit, I'd given the operator column
less space than the others:

   <colspec colname="col1" colwidth="2*"/>
   <colspec colname="col2" colwidth="2*"/>
   <colspec colname="col3" colwidth="1*"/>

which is backwards now, of course.  Perhaps you could just drop the
<colspec>s again, or else twiddle their relative widths.  Some other
recommendations I'd make are:

* Don't use the carpal-tunnel-inducing SQL standard datatype names,
but just "timestamp", "timestamptz", etc.

* Put a space after the comma in each operator description; this will
look better and it will cue FOP that that's a good place for a line
break.

* I'm inclined to think that spaces before the operators' left parens
would improve readabilty, too.


> As I understand it, the cross-type operators are "loose" in the opfamily
> and they don't belong to any opclass.  So what we could do is list the
> opclasses within each opfamily, and then list all the loose operators.
> Something like (fixed width font):
> 
> Operator family      Operator class     Operator
> ------------------------------------------------------------
> integer_minmax_ops   int4_minmax_ops    =(integer,integer)
>                                         <(integer,integer)
>                                         >(integer,integer)
>                                         >=(integer,integer)
>                                         <=(integer,integer)

Hm, do we care quite that much about explaining this difference?
But you're right that we hardly need the "data type" column
per se when the operator column is repeating the same info.

> Thanks for doing the legwork!

Indeed.

			regards, tom lane