Horton

Re: documentation structure

Corey Huinker <corey.huinker@gmail.com>

View thread
From: Corey Huinker <corey.huinker@gmail.com>
To: jian he <jian.universality@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-04-29T05:17:39Z
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 →

  1. docs: Consistently use <optional> to indicate optional parameters

  2. docs: Consolidate into new "WAL for Extensions" chapter.

  3. freespace: Don't return blocks past the end of the main fork.

  4. docs: Merge separate chapters on built-in index AMs into one.

  5. docs: Demote "Monitoring Disk Usage" from chapter to section.

  6. doc: move system views section to its own chapter

>
> I've splitted it to7 patches.
> each patch split one <sect1> into separate new files.
>

Seems like a good start. Looking at the diffs of these, I wonder if we
would be better off with a func/ directory, each function gets its own file
in that dir, and either these files above include the individual files, or
the original func.sgml just becomes the organizer of all the functions.
That would allow us to do future reorganizations with minimal churn, make
validation of this patch a bit more straightforward, and make it easier for
future editors to find the function they need to edit.