Re: Another modest proposal for docs formatting: catalog descriptions - Mailing list pgsql-docs

From Josef Šimánek
Subject Re: Another modest proposal for docs formatting: catalog descriptions
Date
Msg-id CAFp7QwqrKAc+pwLG+zssu1MAi9yaO93+gNm4MLR=43FLtdeDGA@mail.gmail.com
Whole thread Raw
In response to Another modest proposal for docs formatting: catalog descriptions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Another modest proposal for docs formatting: catalog descriptions
Re: Another modest proposal for docs formatting: catalog descriptions
List pgsql-docs


út 2. 6. 2020 v 0:30 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
As of HEAD, building the PDF docs for A4 paper draws 538 "contents
... exceed the available area" warnings.  While this is a nice step
forward from where we were (v12 has more than 1500 such warnings),
we're far from done fixing that issue.

A large chunk of the remaining warnings are about tables that describe
the columns of system catalogs, system views, and information_schema
views.  The typical contents of a row in such a table are a field name,
a field data type, possibly a "references" link, and then a description.
Unsurprisingly, this does not work very well for descriptions of more
than a few words.  And not infrequently, we *need* more than a few words.

ISTM this is more or less the same problem we have/had with function
descriptions, and so I'm tempted to solve it in more or less the same
way.  Let's redefine the table layout to look like, say, this for
pg_attrdef [1]:

oid oid
        Row identifier

adrelid oid (references pg_class.oid)
        The table this column belongs to

adnum int2 (references pg_attribute.attnum)
        The number of the column

adbin pg_node_tree
        The column default value, in nodeToString() representation. Use
        pg_get_expr(adbin, adrelid) to convert it to an SQL expression.

That is, let's go over to something that's more or less like a table-ized
<variablelist>, with the fixed items for an entry all written on the first
line, and then as much description text as we need.  The actual markup
would be closely modeled on what we did for function-table entries.

Thoughts?

I have spotted this change recently at progress monitoring devel docs (https://www.postgresql.org/docs/devel/progress-reporting.html#CREATE-INDEX-PROGRESS-REPORTING). Current version seems a little chaotic since there are multiple tables on the same page with 2 mixed layouts. Older layout (for example v12 one - https://www.postgresql.org/docs/12/progress-reporting.html#CREATE-INDEX-PROGRESS-REPORTING) is much easier to read for me.

Is this final change? I do not see any problem on this (progress monitoring) page in old layout. Is there any example of problematic page? Maybe there's a different way to solve this. For example instead of in-lining long text as a column description, it should be possible to link to detailed description in custom paragraph or table. See description column at table 27.22. at progress monitoring page for column "phase" for similar approach.
 

                        regards, tom lane

[1] https://www.postgresql.org/docs/devel/catalog-pg-attrdef.html




pgsql-docs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Minor result error in binary strings documentation
Next
From: Tom Lane
Date:
Subject: Re: Another modest proposal for docs formatting: catalog descriptions