Re: documentation structure

Corey Huinker <corey.huinker@gmail.com>

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-07-18T20:16:37Z
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

>
>
> looking back.
> The patch is big. no convenient way to review/validate it.
>

Perhaps we can break up the patches as follows:

1. create the filelist.sgml entries, and create new files as you detailed,
empty with func.sgml still managing the sections, but each section now has
it's corresponding &func-something; The files are included, but they're
completely empty.

2 to 999+. one commit per function moved from func.sgml to it's
corresponding func-something.sgml.

It'll be a ton of commits, but each one will be very easy to review.

Alternately, if we put each function in its own file, there would be a
series of commits, one per function like such:

1. create the new func-my-function.sgml, copying the definition of the same
name
2. delete the definition in func.sgml, replaced with the &func-include;
3. new entry in the filelist.

This approach looks (and IS) tedious, but it has several key advantages:

1. Each one is very easy to review.
2. Big reduction in future merge conflicts on func.sgml.
3. location of a given functions docs is now trivial.
4. separation of concerns with regard to content of function def vs
placement of same.
5. Easy to ensure that all functions have an anchor.
6. The effort can stall and be resumed at our own pace.

Perhaps your python script can be adapted to this approach? I'm willing to
review, or collaborate, or both.