Re: documentation structure

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: "David G. Johnston" <david.g.johnston@gmail.com>

Cc: Peter Eisentraut <peter@eisentraut.org>, Andrew Dunstan <andrew@dunslane.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>

Date: 2024-04-05T16:18:30Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

docs: Consistently use <optional> to indicate optional parameters
- 0d829703363b 18.0 landed
docs: Consolidate into new "WAL for Extensions" chapter.
- 09d9800e5282 17.0 landed
freespace: Don't return blocks past the end of the main fork.
- 935829743151 17.0 cited
docs: Merge separate chapters on built-in index AMs into one.
- fe8eaa54420c 17.0 landed
docs: Demote "Monitoring Disk Usage" from chapter to section.
- f470b5c67924 17.0 landed
doc: move system views section to its own chapter
- 64d364bb39cb 16.0 cited

On Fri, Apr 5, 2024 at 12:15 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> Here is a link to my attempt at this a couple of years ago.  It basically "abuses" refentry.
>
> https://www.postgresql.org/message-id/CAKFQuwaVm%3D6d_sw9Wrp4cdSm5_k%3D8ZVx0--v2v4BH4KnJtqXqg%40mail.gmail.com
>
> I never did dive into the man page or PDF dynamics of this particular change but it seemed to solve HTML pagination without negative consequences and with minimal risk of unintended consequences since only the markup on the pages we want to alter is changed, not global configuration.

Hmm, but it seems like that might have generated some man page entries
that we don't want?

-- 
Robert Haas
EDB: http://www.enterprisedb.com