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-26 22:17:59 |
Message-ID: | 2983367.1598480279@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-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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-08-26 22:39:27 | Re: Document "59.2. Built-in Operator Classes" have a clerical error? |
Previous Message | Alvaro Herrera | 2020-08-26 21:58:01 | Re: Document "59.2. Built-in Operator Classes" have a clerical error? |