Horton

Re: documentation structure

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Andrew Dunstan <andrew@dunslane.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-03-20T21:25:45Z
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

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Mar 20, 2024 at 5:05 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> I think you can achieve this with a much smaller patch that just changes
>> the outer tag in each file so that each file is a <sect1>, then create a
>> single file that includes all of these plus an additional outer tag for
>> the <chapter> (or maybe just add the <chapter> in postgres.sgml).  This
>> has the advantage that each AM continues to be a separate single file,
>> and you still have your desired structure.

> Right, that could also be done, and not just for 0003. I just wasn't
> sure that was the right approach. It would mean that the division of
> the SGML into files continues to reflect the original chapter
> divisions rather than the current ones forever. In the short run
> that's less churn, less back-patching pain, etc.; but in the long term
> it means you've got relics of a structure that doesn't exist any more
> sticking around forever.

I'd say that a separate file per AM is a good thing regardless.
Elsewhere in this same thread are grumblings about how big func.sgml
is; why would you think it good to start down that same path for the
AM documentation?

			regards, tom lane