Re: [DOCS] with - Mailing list pgsql-docs
| From | Alexander Law |
|---|---|
| Subject | Re: [DOCS] |
| Date | |
| Msg-id | 6f1a6a95-d36e-8c9e-e0d1-3e273793ad9a@gmail.com Whole thread Raw |
| In response to |
[DOCS] |
| Responses |
Re: [DOCS] |
| List | pgsql-docs |
Hello Alvaro,
These duplicate entries caused by the zone attribute. If you'll remove it, you'll get only single entry (in secondary line).
It seems that the following DocBook bugfix introduced the bug you encountered:
https://github.com/docbook/xslt10-stylesheets/commit/f555842b
I see the following solutions for the issue:
1. To customize this xsl template (remove @zone check) for our docs.
2. To remove @zone specification from indexterm's.
Are there any reasons to specify it explicitly?
<sect2 id="vacuum-for-statistics">
<title>Updating Planner Statistics</title>
<indexterm zone="vacuum-for-statistics">
<primary>statistics</primary>
<secondary>of the planner</secondary>
</indexterm>
(DocBook documentation says:
So here "zone" specifies a single point. But to mark a single point we don't need to specify a zone.
A single point is marked with an
(We have about 800 "zone" specifications, but as the issue arises only with <secondary>, it decreases to about 160 entries.)
3. To report an issue to docbook and get some feedback (but I'm afraid it can take months).
Best regards,
Alexander
15.03.2017 19:05, Alvaro Herrera wrote:
These duplicate entries caused by the zone attribute. If you'll remove it, you'll get only single entry (in secondary line).
It seems that the following DocBook bugfix introduced the bug you encountered:
https://github.com/docbook/xslt10-stylesheets/commit/f555842b
I see the following solutions for the issue:
1. To customize this xsl template (remove @zone check) for our docs.
2. To remove @zone specification from indexterm's.
Are there any reasons to specify it explicitly?
<sect2 id="vacuum-for-statistics">
<title>Updating Planner Statistics</title>
<indexterm zone="vacuum-for-statistics">
<primary>statistics</primary>
<secondary>of the planner</secondary>
</indexterm>
(DocBook documentation says:
Zone holds the IDs of the elements to which it applies.So here "zone" specifies a single point. But to mark a single point we don't need to specify a zone.
A single point is marked with an
IndexTerm placed in the text at the point of reference.)(We have about 800 "zone" specifications, but as the issue arises only with <secondary>, it decreases to about 160 entries.)
3. To report an issue to docbook and get some feedback (but I'm afraid it can take months).
Best regards,
Alexander
15.03.2017 19:05, Alvaro Herrera wrote:
While reviewing Tomas' extended statistics patch I noticed that the new docbook toolchain produces additional links for each indexterm, based on the <secondary> tags there are. For instance, in 9.5 I see this: statistics, Aggregate Functions, The Statistics Collector of the planner, Statistics Used by the Planner, Updating Planner Statistics https://www.postgresql.org/docs/9.5/static/bookindex.html#AEN186176 while in 10 I see this for the same source: statistics, Aggregate Functions, Statistics Used by the Planner, Updating Planner Statistics, The Statistics Collector of the planner, Statistics Used by the Planner, Updating Planner Statistics https://www.postgresql.org/docs/devel/static/bookindex.html#indexdiv-S Note that the links for entries on the <secondary>of the planner</> also show up in the first list of links. Is this intended? As we get more <secondary> entries, this gets busy real quick, for no gain that I can see. For instance, I added this entry: <indexterm zone="extended-statistics"> <primary>statistics</primary> <secondary>of the planner</secondary> <tertiary>extended</tertiary> </indexterm> and this results in: statistics, Aggregate Functions, Statistics Used by the Planner, Updating Planner Statistics, The Statistics Collector, Extended Statistics of the planner, Statistics Used by the Planner, Updating Planner Statistics, Extended Statistics extended, Extended Statistics which seems altogether excessive. Perhaps this is a bug in the index generation? FWIW I'm leaning towards removing the <tertiary> in the new entry, which results in this: statistics, Aggregate Functions, Statistics Used by the Planner, Updating Planner Statistics, The Statistics Collector, Extended Statistics of the planner, Statistics Used by the Planner, Updating Planner Statistics, Extended Statistics I think this would be better: statistics, Aggregate Functions, The Statistics Collector of the planner, Statistics Used by the Planner, Updating Planner Statistics, Extended Statistics
pgsql-docs by date: