From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: osdba <mailtch@163.com>
Cc: pgsql-docs@postgresql.org
Cc: jkatz@postgresql.org
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?
Date: Wed, 26 Aug 2020 18:17:59 -0400
Message-ID: <2983367.1598480279@sss.pgh.pa.us> (raw)
In-Reply-To: <20200826215801.GA30013@alvherre.pgsql>
References: <20200826215801.GA30013@alvherre.pgsql>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, michael@paquier.xyz, bruce@momjian.us, mailtch@163.com, jkatz@postgresql.org
Subject: Re: Document "59.2. Built-in Operator Classes" have a clerical error?
In-Reply-To: <2983367.1598480279@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox