Re: Get rid of "Section.N.N.N" on DOCs - Mailing list pgsql-hackers

From Marcos Pegoraro
Subject Re: Get rid of "Section.N.N.N" on DOCs
Date
Msg-id CAB-JLwb=1YVL3LjbkZPc8O1XtJFy+iAktE8xsnZUThG7c8fp=g@mail.gmail.com
Whole thread Raw
In response to Re: Get rid of "Section.N.N.N" on DOCs  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
Em qui., 25 de dez. de 2025 às 18:41, Laurenz Albe <laurenz.albe@cybertec.at> escreveu:
Overall, I have the impression that the patch is an improvement.
Cool

1. You seem to have taken the chapter heading as label automatically.
   That leads to labels like "Author" and "Deprecation Notice" that are not
   descriptive enough without a reference to the chapter.
   These lables need going over.

Well, I noticed that if the xreflabel tag existed next to the section identifier, then it would be used in the HTML, so all I did was create a regular expression that takes the title from the line below and puts it on the line above. That was the only thing I did. As I wrote before, we need to carefully read and adapt item by item.

2. I notice that you added labels to the sections, but not to the chapters, so
   the references to the chapters still read like "Chapter 63".  Is that deliberate,
   an oversight, or are there problems adding labels to the chapters?
Correct, I didn't do it for Chapters and Tables. I think it would be better to have the word Chapter and then the Title. 
See Chapter 14 for information about how to find out whether an index is used 
for this
See Chapter Performance Tips for information about how to find out whether an index is used 
So, this replacement would always have the Chapter word before, what do you think ? 

And about Tables, do the same ?
The built-in general-purpose aggregate functions are listed in Table 9.62
would be
The built-in general-purpose aggregate functions are listed in Table General-Purpose Aggregate Functions

3. Similarly, you didn't add labels to subsections, so there are still references
   like "Section 66.6.1".  I understand that that might be too much code churn for
   your patch, but the inconsistency is deplorable.
I didn't find this 66.6.1 on my files, are you sure of it ?
My search hadn't found any identifiers with numbers in them, but I improved the expression already.

Comments for the individual changes I scrutinized:
As I mentioned, you need to read it item by item to catch these inconsistencies. And the work is even greater because there's no clear relationship between which SGML file you're editing and which HTML file will be generated, so the task is even more demanding.

regards
Marcos

pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: Introduce Index Aggregate - new GROUP BY strategy
Next
From: "zengman"
Date:
Subject: Re: 17f446784d54da827f74c2acc0fa772a41b92354 breaks orafce build