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

From Tom Lane
Subject Re: Document "59.2. Built-in Operator Classes" have a clerical error?
Date
Msg-id 2983367.1598480279@sss.pgh.pa.us
Whole thread Raw
In response to Re: Document "59.2. Built-in Operator Classes" have a clerical error?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-docs
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



pgsql-docs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?
Next
From: Bruce Momjian
Date:
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?