Re: [DOCS] Stats views and functions not in order?
От | Peter Eisentraut |
---|---|
Тема | Re: [DOCS] Stats views and functions not in order? |
Дата | |
Msg-id | 9efb6489-d256-d8ae-7622-be8ff941c19d@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [DOCS] Stats views and functions not in order? (Peter Smith <smithpb2250@gmail.com>) |
Ответы |
Re: [DOCS] Stats views and functions not in order?
|
Список | pgsql-hackers |
On 19.01.23 00:45, Peter Smith wrote: > The original $SUBJECT requirements evolved to also try to make each > view appear on a separate page after that was suggested by DavidJ [2]. > I was unable to achieve per-page views "without radically changing the > document structure." [3], but DavidJ found a way [4] to do it using > refentry. I then wrote the patch v8-0003 using that strategy, which > after more rebasing became the v10-0001 you see today. > > I did prefer the view-per-page results (although I also only use HTML > docs). But my worry is that there seem still to be a few unknowns > about how this might affect other (not the HTML) renderings of the > docs. If you think that risk is too great, or if you feel this patch > will cause unwarranted link/bookmark grief, then I am happy to just > drop it. I'm wary of making semantic markup changes to achieve an ad-hoc presentation effects. Sometimes it's necessary, but it should be considered carefully and globally. We could change the chunking boundary to be sect2 globally. This is easily configurable (chunk.section.depth). Thinking about it now, maybe this is what we need. As the documentation grows, as it clearly does, the depth of the structure increases and pages get longer. This can also be seen in other chapters. Of course, this would need to be tested and checked in more detail.
В списке pgsql-hackers по дате отправления: